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EXECUTIVE SUMMARY 


Introduction 


This document describes the development of the Regional Intelligent Transportation System (ITS) 
Architecture for Metropolitan Boston. The discussion provides background information on ITS and 
ITS architectures, explains the collaborative process used in Metropolitan Boston to develop the 
architecture and summarizes the important outcomes of the initiative. 


Intelligent Transportation Systems (ITS) are applications of advanced technology in the field of 
transportation, with the goals of increasing operational efficiency and capacity, improving safety, 
reducing environmental costs, and enhancing personal mobility. Successful ITS deployment 
requires an approach to planning, implementation, and operations that emphasizes collaboration 
between relevant entities and compatibility of individual systems. At the core of this process is an 
“ITS architecture” that guides the coordination and integration of individual ITS projects. This ITS 
architecture is a framework that defines the component systems and their interconnections. In 
addition, developing an ITS architecture offers three important benefits to the region: improved 
interagency coordination, cost savings for transportation operations, and better services to the 
traveling public. 


The Commonwealth of Massachusetts, through the Executive Office of Transportation (EOT), has 
undertaken the development of a Regional Intelligent Transportation Systems Architecture for 
Metropolitan Boston. The Office of Transportation Planning (OTP) has led a project team 
consisting of IBI Group in association with ConSysTec Corporation and Rizzo Associates. The 
consultant team also included an advisory panel consisting of James McGrail, Esq. of Nora Burke 
and Co., Paula Okunieff of Systems & Solutions, Inc., and Dr. Joseph Sussman of the 
Massachusetts Institute of Technology. 


Key transportation agencies and other stakeholders in the region provided extensive input in the 
process, with many serving on a Guidance Committee. Their involvement included participating in 
meetings and workshops and reviewing project deliverables. Out of this process, with the help of 
these stakeholders, came an architecture that represents a vision of an integrated transportation 
system for the Metropolitan Boston region and the interagency relationships needed to support it. 


Background 


Technology has influenced almost every facet of modern living, and transportation is no exception. 
By now, most drivers have seen electronic tolling that allows properly equipped vehicles to speed 
through toll plazas instead of waiting in line to collect a ticket or pay a toll. Drivers are also familiar 
with electronic signs on highways that provide information, such as warnings of accidents and 
delays. In many areas, travelers are able to obtain information on traffic conditions and transit 
operations via the internet or by phone. 


These are just a few examples of what are referred to as Intelligent Transportation Systems, or ITS. 
Other examples of ITS are less obvious to the everyday commuter. Traffic signal operators, transit 
agencies, and public safety agencies agree to deploy compatible equipment so that buses and 
emergency vehicles can have priority when approaching a signalized intersection. Transit and 
other vehicles are equipped with Global Positioning Systems (GPS) so that their location can be 
known at all times. Some roadways have sensors installed so that potential icy conditions can be 
detected by a centralized monitoring system and appropriate measures can be implemented. All of 
these various examples, however, have one thing in common: the use of technology to get more 
productivity or value out of the transportation infrastructure and human resources. 
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With the enactment of the Intermodal Surface Transportation Efficiency Act of 1991 (ISTEA), there 
was a policy shift from building roadways to seeking multimodal solutions to congestion and other 
problems. ISTEA specifically promoted ITS as a tool in the transportation planning toolbox. By 
1998, however, when ISTEA was reauthorized, there was a concern that the deployment of ITS 
initiatives lacked coordination, leading to the duplication of efforts and incompatibility of systems. 
The new law, the Transportation Equity Act for the 21st Century (TEA-21) included a provision that 
called for the coordination of ITS investments. 


In 2001, the Federal Highway Administration (FHWA) and Federal Transit Administration (FTA) 
issued guidance on how this federal law was to be carried out around the country. FHWA’s rule, 
“Intelligent Transportation System Architecture and Standards” and FTA’s “National ITS 
Architecture Policy on Transit Projects” established that any ITS project funded by the Highway 
Trust Fund, including the Mass Transit Account, has to be consistent with a Regional ITS 
Architecture, which is to be adapted from a national template. 


In this context, the word “architecture” refers not to a plan of physical construction, such as the 
architecture of a building or city, but instead to the relationship between transportation-related 
systems and institutions. An ITS architecture covers how systems interface and interact, as well as 
the institutional relationships that are required to support these interfaces. A regional ITS 
architecture, therefore, describes how a set of agencies will share responsibility and information for 
the vast array of technologies and systems deployed in a region. 


As an example, a traffic signal may be owned and maintained by the municipality in which it is 
located, but it may be operated by a state highway department if it is adjacent to a roadway in the 
state’s jurisdiction. At the same time, the municipality may agree to allow fire trucks, police cars, 
ambulances, or transit vehicles to use technology that enables such vehicles to trigger a green light 
at the appropriate time. Quickly, one can see that the technical and institutional issues surrounding 
this single traffic signal involve a variety of interfaces, interactions, and responsibilities. Should the 
signal happen to be on or near the boundary with another municipality, it is easy to see how the 
complexity would increase dramatically. A regional ITS architecture is intended to help all of these 
institutions collaborate on the deployment and management of these systems. 


Architecture Development Process 


As the traffic signal example illustrates, the architecture of a single element or system can be quite 
complex, and this complexity quickly escalates when all systems within a region are considered. To 
address this challenge, the USDOT created the National ITS Architecture as a resource for ITS 
planning and implementation. The FHWA Rule/FTA Policy requires the use of the National ITS 
Architecture as a template in the development of regional ITS architectures. 


The National ITS Architecture is not a system design or a plan for deployment; instead it is a model 
that provides a framework for ITS planning and integration. The building block of the National 
Architecture is a market package, which includes the set of components related to a specific 
function or “market,” such as work zone management, parking facility management, demand- 
responsive transit operations, or emergency routing. For each of these market packages, the 
National Architecture includes all of the interagency linkages, or interfaces, considered likely. 
Because the National Architecture was designed to be comprehensive, a regional architecture 
should be a subset, including only those market packages and interfaces relevant to that region. 


CONSTRUCTING THE ARCHITECTURE 
Developing a regional ITS Architecture begins with the strategic question of how to customize the 


National ITS Architecture to regional circumstances. On the one hand, it is necessary to generate 
an inventory of local ITS elements, both existing and planned. On the other hand, it is prudent to 
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work backwards from the National Architecture, eliminating irrelevant market packages and 
interfaces and using the rest to organize the local inventory. 


In Massachusetts, the process also requires addressing the complex question: what is regional? 

As ITS has already been deployed throughout Massachusetts, including both urban and rural areas, 
it was clear that it was important to include all parts of the state. As Exhibit ES-1 illustrates, the 
Commonwealth’s 13 MPO planning areas were grouped into four regions for the purpose of 
creating regional ITS architectures. 


Metropolitan Boston 
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Exhibit ES-1: Study Regions 


This Regional ITS Architecture was developed for the Metropolitan Boston area. For the purposes 
of this study, Metropolitan Boston was defined as the area generally within |-495, Boston’s outer 
circumferential highway. Covering approximately 2,000 square miles, the region includes the 
Boston, Northern Middlesex, and Merrimack Valley MPO planning areas, as well as portions of the 
Old Colony and Southeastern Massachusetts MPO planning areas. 


To ensure consistency throughout the Commonwealth, the Executive Office of Transportation’s 
Office of Transportation Planning (OTP) organized the development of four regional ITS 
architectures. In each region, the process was the same and was led by a guidance committee of 
liaisons from regional stakeholders. Throughout the architecture development process, this 
Guidance Committee provided input, reviewed documents prepared by the Project Team, and 
made critical decisions to achieve consensus about implementation approaches. Each Regional 
ITS Architecture reflects the unique characteristics of its region and stakeholders. 


In the Metropolitan Boston region, numerous agencies were invited to participate in the initial 


meeting or were subsequently invited by the Guidance Committee to participate in the process. 
These agencies are listed in Exhibit ES-2. 
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Exhibit ES-2: Guidance Committee Invitees 





Regional Planning Agencies 


« Metropolitan Area Planning Council 
(MAPC) 


«Merrimack Valley Planning Commission 
(MVPC) 


= Northern Middlesex Council of 
Governments (NMCOG) 


= Old Colony Planning Council (OCPC) 


=" Southeastern Regional Planning & 
Economic Development District (SRPEDD) 


Transit Authorities 
« Brockton Area Transit (BAT) 
"Cape Ann Transportation Authority (CATA) 


"Greater Attleboro-Taunton Regional Transit 
Authority (GATRA) 


= Lowell Regional Transit Authority (LRTA) 


=" Massachusetts Bay Transportation 
Authority (MBTA) 


«Merrimack Valley Regional Transit 
Authority (MVRTA) 


Municipal/Regional Agencies, Authorities, 
Commissions, and Organizations 


" Boston Emergency Management Agency 
(BEMA) 


«Boston Transportation Department (BTD) 
= City of Brockton 








State Agencies 
«Executive Office of Transportation (EOT) 


«» Massachusetts Emergency Management 
Agency (MEMA) 


«" Massachusetts Highway Department 
(MassHighway) 


«Massachusetts Port Authority (Massport) 
«Massachusetts State Police (MSP) 


« Massachusetts Turnpike Authority 
(MassPike), including the Central 
Artery/Tunnel (CA/T) 


= Metropolitan District Commission (MDC)' 
« Registry of Motor Vehicles (RMV) 


Federal Agencies 
« Federal Highway Administration (FHWA) 
= Federal Transit Administration (FTA) 


« Federal Motor Carrier Safety Administration 
(FMCSA) 





Following the kickoff meeting, the Project Team reviewed planning documents, including each 
MPO’s Regional Transportation Plan (RTP) and Transportation Improvement Program (TIP). OTP 
then organized a series of input meetings during which members of the Guidance Committee and 
other stakeholders contributed to the comprehensive inventory of local ITS-related initiatives, 
including those already deployed, those ready for implementation, and those still in the planning 
stages. During this needs-assessment step, stakeholders also discussed the issues facing the 
region and other needs that shape transportation planning and spending. 


Based on this input, the Project Team began assembling the relevant market packages, 
customizing the National ITS Architecture to regional circumstances. At a two-day workshop, the 
Project Team reviewed each and every market package diagram with the Guidance Committee, 
discussing with the committee how input from the previous meetings had been distilled into the 
diagrams presented. This prompted extensive feedback from the Guidance Committee, both at the 
meeting and during the subsequent review period. On the basis of that response, the Project Team 
made revisions and updated the market packages before assembling them into an architecture, 
which was made accessible to the Guidance Committee via an interactive website. 





' As of July 1, 2003, the Metropolitan District Commission (MDC) as an organization no longer exists. Functions formerly carried out by the 
MDC are being distributed among various state agencies. For the purposes of this document, however, “MDC” will continue to be used to 
refer to elements and functions previously under MDC control. 
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As the traffic signal example used earlier 
demonstrates, a regional ITS architecture can 
easily become large and complex when the 
many market packages that comprise the 
National ITS Architecture are taken into 
account. Navigating the architecture as a 
website, however, makes it significantly more 
user-friendly. Links allow a user to investigate 
common questions such as, “If my agency 
engages in a certain project or investment, 
what other agencies are involved?” 
Alternatively, an agency might simply want to 
know all of the other agencies to which it is 
linked in the architecture. A website provides a 
versatile medium for such searches. 


Through this process of identifying existing and 
planned projects as well as general needs, 
preparing market packages, and then building 
and reviewing the architecture, the Guidance 
Committee has produced a regional ITS 
architecture that reflects the needs and 
priorities of the region. The Regional ITS 
Architecture for Metropolitan Boston is now 
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Needs Analysis Outcomes 


During the needs analysis step, the Guidance 
Committee identified key regional needs and 
major themes for the fRegional ITS 


Architecture. These findings helped shape the 
architecture to the unique circumstances of 
the Metropolitan Boston region. 


Regional Needs 

" Safety and Security 
Congestion Management 
Transit Demand 
Paratransit Efficiency 
Information Sharing 
Communications Infrastructure 
Operations and Maintenance 
Access to ITS Data 


Major Themes 
" Security 
« Information Sharing 
*" Communications Infrastructure 
" Operations and Maintenance 





available in an interactive format on the 
internet. The interface allows a user to view the 
architecture in multiple ways and varying levels of detail. The architecture is available on the 
Commonwealth’s website at http: //www.mass.gov/RegionalITSArchitecture. 





BUILDING ON THE ARCHITECTURE 


The Regional ITS Architecture for Metropolitan Boston was constructed with extensive input from 
stakeholders around the region. Having developed an architecture, however, there are important 
questions that must be addressed: What does this mean for a transit authority, a highway 
department, or a metropolitan planning organization? How does the architecture influence the 
development of new plans or projects? When an agency begins work on a project that includes ITS 
elements, how should it take the architecture into account? To address these questions, the Project 
Team and the Guidance Committee developed two additional documents, an Operational Concept 
and an Implementation Plan. 


Operational Concept 


The Operational Concept describes the institutional relationships that must be established in order 
to address the interagency interfaces defined in the architecture. The purpose of the Operational 
Concept is to define the roles and responsibilities of the stakeholders in the implementation and 
operation of the component systems of the architecture. The Operational Concept details the 
requirements of each agency interface defined in the architecture, addressing the information to be 
exchanged, the roles of the interfacing agencies, and the operational agreements that will be 
required. 


The presentation of the Operational Concept in the Final Report includes an inventory of all the 
interagency interfaces. Because there are hundreds of interfaces, the inventory is organized by 
function, such as roadway management or emergency management. The Operational Concept 
chapter also includes an analysis of current and future interagency relationships that might benefit 
from formalization through interagency agreements, samples of which are included in Appendix F of 
the Final Report. 
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Implementation Plan 


The Implementation Plan provides a strategy for achieving the integrated transportation system 
envisioned by the architecture. The Implementation Plan addresses the planned components of the 
architecture, identifying a series of initiatives that can be undertaken to implement these 
components. The Implementation Plan also considers prioritization of the identified multi-agency 
initiatives, identifying candidates for near-term and longer-term implementation. This prioritization is 
based on the needs analysis, the input received from the stakeholders throughout the architecture 
development process, and interdependencies among the initiatives. As Exhibit ES-3 shows, there 
are ten Near-Term Multi-Agency Initiatives recommended by the Guidance Committee for 
Metropolitan Boston. 


Exhibit ES-3: Recommended Near-Term Multi-Agency Initiatives 





Functional 


Aiea Initiative 





« Event Reporting System: Internet-based tool that serves as a centralized 
repository for information on events affecting the transportation network. 


« Expansion of the Massachusetts Interagency Video Information System 
(MIVIS): Expansion of video sharing and distribution system to allow sharing 
of real-time video feeds among a larger group of agencies. 


Multimodal | = Interagency Communications Network: Communications network linking 
the region’s roadway and transit agencies. 


= 511 Travel Information System: Public travel information system, covering 
the roadways and transit services in the region. 


Planning Data Archive: System for coordinating the planning data archives 
for the transportation agencies in the region. 





" Remote MassHighway TOC Workstation (MassHighway and MEMA): 
Back-up workstation for the MassHighway Traffic Operations Center at MEMA 
headquarters in Framingham. 


Interface between MassHighway TOC and MassPike CA/T OCC: Direct 
data interface between the MassHighway Traffic Operations Center and the 
MassPike CA/T Operations Control Center to support exchange of traffic data. 


Roadway 





Traffic Signal Priority for MBTA Buses: Extension of the signal priority 
Transit system currently in place on the Silver Line to other bus routes in the MBTA 
system. 





« Logan Parking Management System: Parking Management System for the 


Parkl parking facilities at Logan Airport. 
arkin 
2 « ETC Integration at MBTA Parking Facilities: Acceptance of the regional 


electronic toll collection transponders at MBTA-operated parking facilities. 














WORKING WITH THE ARCHITECTURE 


The FHWA Rule and FTA Policy include two important provisions that motivated the Project Team 
and the Guidance Committee to focus on how ITS and the Regional ITS Architecture can be 
integrated into the mainstream transportation planning process. First, the Rule/Policy requires that 
before the architecture is completed, there must be a process put in place for maintaining the 
architecture in the future, as needs evolve and implementation continues. Second, the Rule/Policy 
states that federal approval and funding cannot be given to a project with ITS elements unless it is 
consistent with the architecture. To address these requirements, plans for maintaining the 
architecture and for ensuring project consistency have been developed. 


Page ES-6 


EXECUTIVE SUMMARY REGIONAL ITS ARCHITECTURE FOR METROPOLITAN BOSTON 


March 2005 


Consistency 


“The final design of all ITS projects funded with highway trust funds shall accommodate the 
interface requirements and information exchanges as specified in the regional ITS 
architecture. If the final design of the ITS project is inconsistent with the regional ITS 
architecture, then the regional ITS architecture shall be updated.” — FHWA Rule/FTA Policy 


In plain terms, this regulatory language means that if an agency makes a commitment in the 
architecture, such as sharing the data generated by a system it plans to deploy in the future, then 
when it actually begins developing that element as a part of a project, the project should be 
consistent with the architecture. Consistency may be a matter of technical design or a matter of 
institutional coordination but the requirement essentially says that commitments should be honored. 
The language is very clear, however, that if there is a conflict, the architecture should be updated to 
accommodate the project. 


The Guidance Committee and Project Team, working with the FHWA Rule/FTA Policy, developed a 
process for ensuring that consistency between projects with ITS elements and the Regional ITS 
Architecture would be addressed in the course of the existing regional transportation planning 
process. This process reflects the intent of the Rule/Policy that the relationship between a project 
and the architecture should be considered early and often and that collaboration and cooperation 
among planning partners should be maximized. 


As noted, a major objective in addressing the consistency requirement was to develop a process 
that could be integrated seamlessly into the mainstream transportation planning process. As such, 
the process relies on existing collaborative relationships between each MPO and its local planning 
partners. This approach ensures that before a project reaches the Transportation Improvement 
Program (TIP), the Rule/Policy’s intent of examining consistency early and often and maximizing 
collaboration will be fulfilled. In turn, when each MPO submits its TIP to the Executive Office of 
Transportation and when EOT submits the Statewide TIP to FHWA and FTA, all parties will be 
comfortable that the consistency requirement has been addressed. 


In addition to this initial review in the early stages of the project development process, consistency 
with the architecture must be revisited as a project develops further in order to ensure that it has not 
been affected by changes to the scope of the project. Moreover, as a project progresses into the 
design stage, it must undergo a systems engineering analysis, as is typical of ITS projects and as is 
required by the federal Rule and Policy. 


The bottom line is that by examining consistency early and often during the planning process and 
by maximizing collaboration and cooperation — all within the context of existing practices — the 
region can avoid any delays to federal funding and approval. 


Maintenance 


The Regional ITS Architecture is a vision of the future transportation system, documented at one 
point in time. The architecture, like an MPO’s Regional Transportation Plan (RTP), reflects the 
current situation and documents planned changes or investments. However, in order to remain 
relevant, the architecture has to be maintained. As regional needs evolve, as planned elements are 
deployed, and as other changes occur, the architecture must be updated to reflect those 
developments. Maintenance of the architecture is also motivated by federal requirements that 
require consistency between all federally funded projects with ITS elements and the Regional ITS 
Architecture. 


The Office of Transportation Planning, which has led the initial development of the Regional ITS 
Architecture, will be responsible for the maintenance of the architecture. However, other 
stakeholders will be involved, as they have been throughout the development process. The 
maintenance strategy relies on two elements: 
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= Periodic Architecture Updates 


The maintenance strategy calls for the Regional ITS Architecture to be formally updated at the 
same frequency as an MPO’s Regional Transportation Plan (currently a three-year cycle). 
Since the RTPs will provide valuable input to the architecture, the architecture update process 
will be staggered to occur after the RTP update. In this way, it is expected that the revised 
architecture can incorporate new ideas and/or projects that are included in an updated RTP. 


The Office of Transportation Planning will initiate the Regional ITS Architecture update process 
with a request for information from stakeholders in the region regarding new ITS-related 
projects, initiatives, or needs. OTP will also gather information from the stakeholders in order to 
evaluate the status of the architecture’s implementation, identifying, for example, ITS elements 
or interfaces that have evolved from “planned” to “existing” or that are no longer relevant and 
should be removed. 


Based on the information gathered through this process, OTP will generate a draft list of 
architecture modifications and distribute it to the stakeholders for review. OTP can then calla 
stakeholder meeting for the region to review the draft list. This meeting can also provide an 
opportunity to discuss emerging ITS issues. After the stakeholder review of the draft list, OTP 
will make any modifications necessary and release the updated architecture. 


= Interim Architecture Modifications 


The strategy also calls for interim architecture modifications that may occur at any point in the 
update cycle, outside of the formal update process. Just as project developments necessitate 
TIP amendments, it is anticipated that some modifications to the architecture will be needed 
during the interval between the periodic updates. Therefore, on the basis of project 
developments or other circumstances that require modifications, the project proponent will be 
responsible for drafting an architecture modification proposal and submitting it to OTP. The 
proposal will then be circulated to affected stakeholders for their review. It is expected that most 
architecture modifications, whether periodic or interim, will involve adding new ideas, 
dimensions, or stakeholders to existing market packages, interfaces, or functions. 


CONCLUSION 


The Regional ITS Architecture for Metropolitan Boston is the result of the significant efforts and 
contributions of the participants in the process and it provides a strong foundation and opportunity 
for moving forward with ITS planning and implementation in the region. This process of developing 
the architecture was motivated by the federal requirements and by the benefits of having a regional 
ITS architecture. 


The first of these benefits is improved interagency coordination. The architecture development 
process addresses this objective not only in the recommendations that have come out of the 
architecture, but also through the process of developing the architecture itself. The establishment 
of the multi-agency stakeholder group that met throughout the architecture development process is 
a significant step towards coordinating ITS planning in the region. The numerous meetings and 
workshops of the Guidance Committee demonstrated the benefit of such a forum to exchange 
information on needs and project plans. The maintenance plan for the architecture offers an 
opportunity for this interaction to continue, with mutual benefits for all of the participants. 


The second benefit is cost savings, which is addressed through the recommendations of the 
architecture. For example, coordination of investments and consideration of standards for 
interagency interfaces offer opportunities for cost savings, especially in terms of long-term 
maintenance and operational costs. 
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The third benefit is better services to the traveling public. The public has the potential to benefit 
from this process, as the architecture addresses needs and priorities that cut across agency lines 
and that are not able to be addressed through single-agency initiatives. The framework outlined by 
the architecture is for a regional transportation system that can provide the public with a seamless 
and consistent travel experience across multiple agency jurisdictions. 


RECOMMENDATIONS 


Through the process and from the results of developing the Regional ITS Architecture, including the 
Operational Concept and Implementation Plan, a number of recommendations should be 
considered as the region continues to move forward with deployment of ITS: 


«Of the initiatives in the Implementation Plan, the ten “near-term” multi-agency initiatives 
identified by the Guidance Committee and shown in Exhibit ES-3 are vital for working towards 
the integrated transportation system envisioned by the architecture. Although not as urgent in 
the short term, the remaining “future” multi-agency initiatives are also important in that they 
provide the foundation for interagency coordination throughout the region. 


= Formal agreements should be established for the interagency interfaces identified in the 
architecture. This includes existing interfaces as well as new ones. Existing informal 
agreements should be formalized in order to ensure that their benefits are maintained. This 
can be achieved through new agreements that document specific existing working 
arrangements. Operational agreements for new interfaces should be drawn up as these new 
interfaces are established. Proper documentation of the arrangement will be easiest in the 
planning stages and will facilitate implementation and operation in the long term. 


« ITS architecture consistency should be incorporated into the existing MPO transportation 
planning process. While the process outlined in the Implementation Plan identifies times when 
the consistency issue should be addressed, consideration of the architecture throughout the 
project development process will ensure a satisfactory outcome. 


= The Regional ITS Architecture should be updated to reflect the changing needs and priorities of 
the region. To make this work with the existing transportation planning process, it is 
recommended that the architecture be updated regularly to reflect the needs identified in the 
Regional Transportation Plans in the region. In addition, informal updates to ensure 
consistency with newly proposed projects should be done on an as-needed basis. 


= The agencies and organizations that were represented on the Guidance Committee, as well as 
other relevant ITS stakeholders, should continue to meet and remain involved, not only in the 
maintenance of the architecture, but also in coordinating ITS in the region. The benefits of this 
working group that have been realized in the architecture development process should be built 
upon as the transportation system envisioned by the architecture takes shape. 


USING THE ARCHITECTURE 


This process has yielded a valuable tool for planners and operators of the region’s transportation 
system and there are a number of ways in which the architecture should be used: 


First, the architecture should be used by agencies as a framework for planning ITS projects, as it 
documents what they have planned, as expressed in the architecture development process. If it 
does not reflect the current plans, it should be revised so that it is up to date. 


Second, agencies should use the architecture as a guide to how they should interface with other 


agencies. The ITS architecture documents the interfaces that are planned for development, as well 
as standards that are relevant to these interfaces. In addition, the Operational Concept details the 
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operational arrangements that are required for managing these interfaces and provides a model for 
the interagency agreements that should be established. 


Finally, the Regional ITS Architecture provides the basis for satisfying the federal architecture 
consistency requirement for projects with ITS elements. Therefore, it is vital that project proponents 
use the architecture as a guideline during project development, just as the FHWA and FTA will be 
using the architecture when considering whether to approve the project. It is also important that 
consistency with the architecture is revisited throughout the project development process and as 
part of the systems engineering analysis that is required of all ITS projects. Incorporating the 
architecture into the planning, design, and operations process will ensure that all stakeholders in 
the region are moving together towards the vision that they have created through this process. 


To make sure that the Regional ITS Architecture for Metropolitan Boston is readily available to 
stakeholders, the architecture has been published on the Commonwealth’s website at 
http://www.mass.gov/RegionallITSArchitecture. 
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1. INTRODUCTION 


This document describes the development of the Regional Intelligent Transportation System (ITS) 
Architecture for Metropolitan Boston. Intelligent Transportation Systems are applications of 
advanced technology in the field of transportation, with the goals of increasing operational efficiency 
and capacity, improving safety, reducing environmental costs, and enhancing personal mobility. 
Successful ITS deployment requires an approach to planning, implementation, and operations that 
emphasizes collaboration between relevant entities and compatibility of individual systems. At the 
core of this process is an architecture that guides the coordination and integration of individual ITS 
deployment projects. This ITS architecture is a framework that defines the component systems and 
their interconnections, and that provides a tool for facilitating institutional relationships within a 
region. 


The Commonwealth of Massachusetts, through the Executive Office of Transportation (EOT), has 
undertaken the development of a Regional Intelligent Transportation Systems Architecture for 
Metropolitan Boston. The Office of Transportation Planning (OTP) has led a project team 
consisting of IBI Group in association with ConSysTec Corporation and Rizzo Associates. The 
consultant team also included an advisory panel consisting of James McGrail, Esq. of Nora Burke 
and Co., Paula Okunieff of Systems & Solutions, Inc., and Dr. Joseph Sussman of the 
Massachusetts Institute of Technology. 


Key transportation agencies and other stakeholders in the region provided extensive input in the 
process, with many serving on a Guidance Committee. Their involvement included participating in 
meetings and workshops and reviewing project deliverables. Out of this process, with the help of 
these stakeholders, came an architecture that represents a vision of an integrated transportation 
system for the Metropolitan Boston region and the interagency relationships needed to support it. 


This report documents the development of the Regional ITS Architecture, including both its process 
and its outcome. The report serves as a complement to the CD-ROM included in Appendix A, 
which presents the architecture in an interactive format. More information on the CD, including 
instructions on navigating the architecture, is provided in Chapter 4 of this report. 


1.1 Background 


The development of a regional ITS architecture is part of the federal requirements meant to 
encourage regional integration of transportation systems. ITS has a history that predates the 1991 
Intermodal Surface Transportation Efficiency Act (ISTEA), but that landmark federal legislation 
ushered in an era of transportation planning and programming that placed greater emphasis on 
regional systems analysis, interagency collaboration, and multimodal thinking. It also explicitly 
marked the end of the interstate highway era, which had produced over 40,000 miles of interstate 
since the mid-1950s. With limited ability to expand capacity, many metropolitan areas began 
looking for ways to better utilize existing infrastructure, a task for which ITS is ideally suited. 


Throughout the 1990s, the U.S. Department of Transportation (USDOT) guided the development of 
ITS through the National ITS Program, which addressed three main areas: research, field testing, 
and deployment support. The first two of these areas covered specific projects and initiatives. 
Research initiatives included projects such as ITS analysis and technology development efforts, 
while field projects included operational tests such as the ITS Priority Corridors Program. In 
contrast, deployment support focused more generally on ITS planning, specifically through the Early 
Deployment Planning Program. This program assisted in the development of numerous strategic 
deployment plans, which provided recommended approaches for deployment of ITS to address 
regional needs. 


Building on the initiatives established in ISTEA, the Transportation Equity Act for the 21st Century 
(TEA-21) was enacted in 1998. TEA-21 included a requirement for ITS projects funded through the 
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highway trust fund, including the mass transit account, to conform to the National ITS Architecture 
and applicable standards. In January 2001, an FHWA Rule and FTA Policy were published that 
implemented the ITS architecture requirement of TEA-21. The Rule and Policy require that any ITS 
project funded with highway trust funds, including the mass transit fund, be consistent with the 
relevant regional ITS architecture. 


In this context, the word “architecture” refers not to a plan of physical construction, such as the 
architecture of a building or city, but instead to the relationship between transportation-related 
systems and institutions. An ITS architecture covers how systems interface and interact, as well as 
the institutional relationships that are required to support these interfaces. A regional ITS 
architecture, therefore, describes how a set of agencies will share responsibility and information for 
the vast array of technologies and systems deployed in a region. 


The Rule and Policy also require that all ITS projects be based on a systems engineering analysis. 
Such an analysis is typical of any transportation engineering project involving the application of 
advanced technology. For reference, including further information on the systems engineering 
requirement, the FHWA Rule and FTA Policy are attached in Appendices B and C, respectively. 


The Regional ITS Architecture for Metropolitan Boston was developed with consideration of these 
federal requirements. Accordingly, it was developed based on the National ITS Architecture and 
following guidance provided by USDOT. Further information on the National ITS Architecture and 
its requirements is available online from the FHWA’s ITS Architecture Implementation Program, 
which is located at http: //www.ops.fhwa.dot.gov/its_arch_imp/index.htm. Asa 
further aid, Appendix D provides a glossary of architecture terms from the National ITS Architecture. 


1.2 Benefits 


Although the Metropolitan Boston Regional ITS Architecture has been developed to satisfy federal 
requirements, there are a number of other benefits that result from developing this architecture for 
the region: 





«Improved Interagency Coordination: One important benefit is improved interagency 
coordination, which is essential for integration of ITS within the region and for the 
transportation system as a whole. The architecture development process, therefore, seeks 
to facilitate communication among the region’s agencies, providing an opportunity for 
agencies to find out what others are doing in terms of ITS. The architecture process also 
includes the definition of operational concepts for interagency interfaces, as well as 
recommendations for agreements among agencies. 


"Cost Savings: Cost savings are another potential benefit of the regional architecture. The 
primary means of lowering costs is the coordination of capital investment among agencies, 
which reduces duplication of effort and allows more efficient investment. This coordination 
can result in lower overall costs for the agencies in the region. Another means is through 
adherence to standards. Adoption of standards can result in long-term maintenance cost 
savings, since standards allow competition among ITS industry suppliers, leading to lower 
costs for operating agencies. Use of standards also facilitates future system upgrades and 
expansion by reducing the potential for obsolescence. 


= Improved Services to the Public: The regional architecture will help the agencies in the 
region provide better services to the public, specifically in terms of consistency across 
agency jurisdictions. An example of this is provision of multimodal travel information, which 
requires coordination by multiple agencies. Another example is interoperability of electronic 
toll collection systems or transit fare cards, which requires technical and institutional 
agreements. The role of the architecture is to define the requirements for this institutional 
coordination, with the goal of a seamless transportation experience for the end user. 
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1.3 Definition of the Region 


This Regional ITS Architecture was developed for the Metropolitan Boston area, as shown in 
Exhibit 1-1. In addition to the Metropolitan Boston region, regional ITS architectures were also 
developed for the regions of Southeastern, Central, and Western Massachusetts, ensuring that all 
parts of the Commonwealth are covered by a regional ITS architecture. 


Central MA Metropolitan Boston 
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Exhibit 1-1: Study Region 


For the purposes of this study, Metropolitan Boston was defined as the area generally within |-495, 
Boston’s outer circumferential highway. Covering approximately 2,000 square miles, the study 
region includes Boston, Northern Middlesex, and Merrimack Valley MPO planning areas, as well as 
portions of the Old Colony and Southeastern Massachusetts MPO planning areas. 


14 Process 


The process undertaken for the development of the Regional ITS Architecture for Metropolitan 
Boston is illustrated in Exhibit 1-2. 
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Exhibit 1-2: Architecture Development Process 
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The first step of this process was the Needs Analysis, which identifies the ITS-related projects and 
needs of the operating and planning agencies in the region. This analysis served as the basis for 
the development of the functional requirements of the ITS Architecture and its component systems, 
developed in the following step. This approach ensured that the systems recommended for 
implementation, as well as the architecture that provides a framework for these systems, were 
consistent with the needs and goals of the region. Planning documents from the region, including 
Regional Transportation Plans (RTPs) and Transportation Improvement Programs (TIPs), were 
reviewed as part of the needs analysis. Further information was obtained at a meeting of the 
Guidance Committee and through follow-up meetings with individual agencies. 


The next step in the process was the development of the ITS Architecture, which defines the 
existing and planned component systems and the interfaces among them. As with the needs 
analysis, stakeholder involvement was critical to this step of the process. An initial draft of the 
architecture was developed from an inventory of ITS elements identified in the needs analysis and 
from stakeholder input at an architecture development workshop. Refinements to the architecture 
were made following stakeholder review, including a series of follow-up review meetings with 
various groups of stakeholders. Final refinements to the architecture were made once the 
architecture process was completed, allowing the architecture to reflect all of the comments 
received. 


The next two steps resulted in documents derived directly from the ITS architecture. The first was 
the development of the Operational Concept, which describes the institutional relationships that 
must be established in order to address the interagency interfaces defined in the architecture. The 
purpose of the Operational Concept is to define the roles and responsibilities of the stakeholders in 
the implementation and operation of the component systems of the architecture. The Operational 
Concept details the requirements of each interagency interfaces in the architecture, addressing the 
information to be exchanged, the roles of the interfacing agencies, and the operational agreements 
that will be required. 


The final piece of the architecture development process was the development of the 
Implementation Plan, which provides a strategy for achieving the integrated transportation system 
envisioned by the architecture. The Implementation Plan addresses the planned components of the 
architecture, identifying a series of initiatives that can be undertaken to implement these 
components. The Implementation Plan also considers prioritization of the identified multi-agency 
initiatives, identifying candidates for near-term and longer-term implementation. This prioritization is 
based on the needs analysis, the input received from the stakeholders throughout the architecture 
development process, and interdependencies among the initiatives. Also included in this step was 
the development of a plan for maintaining the architecture and ensuring consistency between the 
architecture and projects with ITS components. Due to its importance, this topic is discussed 
separately in Chapter 7 of this report. 


1.5 Organization of the Report 


This Final Report details the process undertaken in the development of the Regional ITS 
Architecture for Metropolitan Boston, and provides the results and recommendations from each of 
the steps of this process. The remainder of the report is structured as follows: 


= Chapter 2 discusses the stakeholder involvement process. 

«Chapter 3 presents the results of the Needs Analysis. 

«Chapter 4 discusses the Regional ITS Architecture and website. 

«Chapter 5 presents the Operational Concept. 

= Chapter 6 presents the Implementation Plan. 

«Chapter 7 discusses architecture maintenance and project consistency. 

« Finally, Chapter 8 presents conclusions from the architecture development process. 
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2. STAKEHOLDER INVOLVEMENT 


To ensure that a regional ITS architecture fully addresses the needs of a region, the architecture 
development process requires input and participation of numerous agencies and organizations. 
The stakeholders in the process should include any stakeholder involved in planning or operating 
transportation systems in the region. This chapter identifies these stakeholders and describes their 
involvement in the architecture development process. 


2.1 Committee Composition 


Federal guidance for developing a regional ITS architecture suggests use of a guidance committee 
that informs and contributes to the process. At the outset of this project, a comprehensive list of 
stakeholders was compiled, including municipal, regional, state, and federal agencies, as well as 
academic institutions and other committees and organizations with relevance to transportation and 
ITS in Metropolitan Boston. From this pool of stakeholders, members were invited to sit on the 
Guidance Committee who broadly represented the agencies and organizations involved in 
transportation in the region. The following stakeholders were invited to participate in the initial 
meeting or were subsequently invited by the Guidance Committee: 


" Regional Planning Agencies 
2 Metropolitan Area Planning Council (MAPC) 
2 Merrimack Valley Planning Commission (MVPC) 
2 Northern Middlesex Council of Governments (NMCOG) 
2 Old Colony Planning Council (OCPC) 
2 Southeastern Regional Planning & Economic Development District (SRPEDD) 


« Transit Authorities 
2 Brockton Area Transit (BAT) 
2 Cape Ann Transportation Authority (CATA) 
2 Greater Attleboro-Taunton Regional Transit Authority (GATRA) 
2 Lowell Regional Transit Authority (LRTA) 
2 Massachusetts Bay Transportation Authority (MBTA) 
ao Merrimack Valley Regional Transit Authority (MVRTA) 


« State Agencies 
2 Executive Office of Transportation (EOT) 
2 Massachusetts Emergency Management Agency (MEMA) 
2 Massachusetts Highway Department (MassHighway) 
2 Massachusetts Port Authority (Massport) 
2 Massachusetts State Police (MSP) 
2 Massachusetts Turnpike Authority (MassPike), including the Central Artery/Tunnel (CA/T) 
« Metropolitan District Commission (MDC) * 
2 Registry of Motor Vehicles (RMV) 


«  Municipal/Regional Agencies, Authorities, Commissions, and Organizations 
2 Boston Emergency Management Agency (BEMA) 
2 Boston Transportation Department (BTD) 
2 Central Transportation Planning Staff (CTPS), technical staff to the Boston MPO 
2 City of Brockton 





TP’PT As of July 1, 2003, the Metropolitan District Commission (MDC) as an organization no longer exists. Functions formerly carried out 
by the MDC are being distributed among various state agencies. For the purposes of this document, however, “MDC” will continue to be 
used to refer to elements and functions previously under MDC control. 
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"Federal Agencies 


Qa 


Oo 


Qo 


Federal Highway Administration (FHWA) 
Federal Transit Administration (FTA) 
Federal Motor Carrier Safety Administration (FMCSA) 


2.2 Participant Meetings 


The Guidance Committee met throughout the project to review and provide input for each phase of 
the process. While participation by the invited committee members varied, the participants in the 
meetings represented a broad cross-section of the agencies listed above. At each stage — needs 
analysis, architecture, operational concept, and implementation plan — the committee reviewed 
project documents and provided input. In addition, a number of smaller group meetings with 
agencies were also held during the process to assist in information collection. For reference, 
Appendix E lists the names and affiliations of all meeting attendees. The following meetings were 
held as part of the architecture development process: 
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Guidance Committee Meetings: In these meetings, held throughout the architecture 
development process, the project team briefed the Guidance Committee on the progress of 
the project, presented new material to the attendees, and solicited feedback on material that 
had been circulated among the committee members. These meetings also offered 
Committee members an opportunity to provide input on issues relating to the architecture 
process. 


Individual Stakeholder Meetings: In the initial stages of the project, meetings were held 
with individual stakeholders to review preliminary information received and to clarify 
questions that had arisen in the review of this material and in early Guidance Committee 
meetings. Meetings were held with MassHighway, CTPS, BTD, MBTA, MassPike, 
Massport, SRPEDD, and RMV. 


Architecture Input Workshop: The purpose of this workshop, which was attended by the 
Guidance Committee members, was to review and further develop the preliminary ITS 
architecture, ensuring that it accurately reflects the existing and planned ITS efforts in the 
region. In this workshop, the project team reviewed the architecture interactively with the 
stakeholders, revising the inventory and interface details based on information provided by 
the participants. The input from this workshop was used to develop the initial Draft Regional 
ITS Architecture. 


Architecture Review Sessions: In these sessions, the members of the Guidance 
Committee met in break-out groups to review the relevant portions of the architecture and to 
provide feedback. Four meetings were held, organized around the following functions: 
Traffic Management and Information Sharing, Signals and City Street Control, Transit and 
Regional Planning, and Emergency Management. The focus of the review was those 
interfaces that crossed institutional boundaries to assure that there was consensus between 
the affected agencies. Relevant comments received during the comment period were also 
discussed in this workshop. The input received in this workshop was incorporated into the 
Final Regional ITS Architecture. 
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3. NEEDS ANALYSIS 


The creation of a regional architecture is based on an assessment of needs among the 
architecture’s stakeholders. Existing documents, studies, and reports, including the Transportation 
Plans and TIPs for each planning region, provided initial information about regional transportation 
needs and certain ITS deployments in the region. This assessment was reviewed at the initial 
meeting of the Guidance Committee. At the subsequent stakeholder input meetings, further 
information was collected, resulting in an inventory of existing or planned ITS elements and known 
areas of need for the region. These needs continued to evolve and be refined throughout the 
architecture development process. 


This chapter summarizes the results of the needs analysis. The first section presents general 
needs identified for the region through the architecture development process. The second section 
presents the inventory of existing and planned systems and initiatives relating to ITS, as well as 
agency-specific needs that were raised. The final section discusses how the results of the needs 
analysis were used in moving forward with the architecture development process. 


3.1 Regional Needs 


Through this assessment, a number of general needs have been identified for the region. These 
needs, obtained from documentation and input from the Guidance Committee, are not specifically 
ITS needs. Instead, these are identified regional transportation needs that have the potential to be 
addressed through the use of ITS. The following are the identified need areas: 


«" Safety and Security — In the wake of 9/11, safety and security concerns were at the top of the 
list for many agencies in the region. Specific needs that were identified included increased 
surveillance capabilities (via CCTV, for example) for public areas and key infrastructure 
elements, improved coordination with emergency management personnel coordinators, and 
securing and providing redundancy in the communications infrastructure. 


= Congestion Management — Recurring congestion on roadways was identified as an issue 
throughout the region. This included delays on major highways (including Interstates and major 
State highways), other State routes, as well as specific intersections and town centers in the 
region. ITS was identified as a potential means for improving congestion by providing 
information to motorists about delays and by allowing them to adjust their travel accordingly. 


= Transit Demand — The need for increased transit service was seen as an issue in many parts 
of the region. This spanned many transit modes, including subway service in the Boston area, 
commuter rail, buses, as well as paratransit. Public demand was seen as driving this need, in 
terms of providing better service to existing riders as well as improving service to raise 
ridership. New demand patterns also need to be addressed, such as the growing demand at 
suburban workplaces. In the case of commuter rail, capacity of parking lots was also identified 
as an issue, as parking at many stations is not adequate for the demand. 


«  Paratransit Efficiency — Another need related to transit is more effective use of paratransit. 
Due to the high per-trip subsidy for paratransit, the Regional Transit Agencies want to improve 
the efficiency of paratransit operations, including coordinating better with fixed-route transit and 
combining paratransit trips. 


« Information Sharing — An issue that was often raised by the operating agencies in the region 
was the need for information from other agencies. The information that was seen as valuable 
included traffic data, information on incidents or other events, and video feeds from other 
agencies. This need cut across all modes and functions in the region. For example, agencies 
with transit management functions desire information from other transit agencies (for 
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coordinating service, e.g.) as well as information from traffic management agencies (for 
information on road conditions, e.g.). As another example, emergency management agencies 
look for information from all other operating agencies in order to evaluate the state of the 
transportation network for response planning. This need was seen as especially critical in the 
Boston area, where management of the transportation system is shared by a large number of 
agencies. 


* Communications Infrastructure — In addition to external information needs, agencies also 
require communications infrastructure to support their internal operating needs. This includes 
communications between field equipment and control centers, as well as among centers within 
a single agency with different functions (transit management vs. emergency management, 
e.g.). Much of this need is currently being met through the use of leased communications lines 
from local phone service providers. Many agencies cited the high monthly costs of these 
leased lines as the primary factor driving the need for dedicated communications infrastructure. 


=" Operations and Maintenance - Staffing requirements for operating and maintaining ITS 
deployments was another concern raised by agencies in the region. Concern was expressed 
both about the additional burden on operational staff (control center operators, e.g.) as new 
systems are deployed, as well as the need for specialized knowledge by those maintaining the 
systems. 


=" Access to ITS Data — The ITS systems already in place in the region offer a significant 
resource for transportation data. This includes both real-time data that can be used for 
operations, as well as archived data that can be used for planning purposes. Planning 
agencies in the region expressed interest in having access to these data sources. 


3.2 ITS Inventory 


Many of the needs discussed above are presently being addressed through initiatives by the 
agencies in the region. In addition to considering regional needs and concerns, the needs analysis 
process also considered the existing and planned ITS initiatives in the region. This section 
presents the ITS inventory, arranged by functional area, in Exhibit 3-1 through Exhibit 3-4. The 
exhibits also include key issues and priorities that were identified by stakeholders during the needs 
analysis. 


Exhibit 3-1: ITS Inventory - Emergency Management 





Existing Systems and «Massachusetts State Police 
Ongoing Initiatives: a *SP and wireless 911 
a Video from MassPike and Massport 
a Amber Alert 
= MEMA 
2 Incident Command System 
2 Emergency Operations Center (EOC) and Web-EOC system 
2 Backup for MassHighway TOC 
a 800 MHz trunked radio system 





Planned and Proposed | = Massachusetts State Police 








Initiatives: 2 Crash Data System (with RMV and MassHighway) 
Agency Issues and «Massachusetts State Police 
Priorities: a Video surveillance of roadways 
a Increased speed of accident reconstruction (to open roads more 
quickly) 
= MEMA 


=o Information coordination and dissemination 
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Exhibit 3-2: ITS Inventory — Roadway (Existing/Ongoing) 





Existing Systems and 
Ongoing Initiatives: 








Massachusetts Highway Department 


a a a a a a a oO o a o a 


SmarTraveler (Travel Information Service Provider) 
CaresVans (roadway service patrols) 

I-93 Integrated Traffic Management System (ITMS) 

Route 128 Advanced Traffic Management System (ATMS) 
Southeast Expressway HOV lane 

Traffic Operations Center (TOC) 

Variable Message Signs (VMSs) 

Emergency motorist call boxes 

Weather stations 

Amber Alert 

GPS on snowplows 

Massachusetts Interagency Video Information System (MIVIS) 


pidssac ects Turnpike Authority 


a 


oO o ia) o o oO a a a 


CA/T Integrated Project Control System (IPCS) 
Integration of Metropolitan Highway System 

Security Program (CA/T and Prudential tunnels, CCTV and 
motion detectors) 

Security system for entire Turnpike 

Traffic webcams 

800 MHz radio conversion (compatible with State Police) 
Fiber-optic cable along Turnpike 

FAST LANE electronic toll collection 

Weather stations 

Variable Message Signs (VMS) 

Coordination with BTD on traffic signals 

Amber Alert 


City of Boston 


a a oO o oO oO o 


Traffic Management Center (TMC) 

Centralized signal control 

CCTV monitoring 

Signal priority for Silver Line 

Signal timing coordination with MBTA 

Traffic coordination with CA/T (including CCTV sharing) 
Incident notification via pager 


Massachusetts Port Authority 


Qo 
ao 
a 
Oo 


Oo 


ao 


Tobin Bridge ETC 

Gate Management / Flight Information Display System (FIDS) 
Logan Travel Information Website 

Logan Parking Management / Revenue Control System, 
including pay-on-foot stations 

Security improvements 

Logan Express buses as probe vehicles for SmarTraveler 


Metropolitan District Commission 


ao 


Traffic signals connected to BTD signal system 


City of Brockton 


Oo 


Traffic signal coordination 
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Exhibit 3-3: ITS Inventory — Roadway (Planned/Proposed, Issues/Priorities) 





Planned and Proposed 
Initiatives: 


Massachusetts Highway Department 

a 511 Travel Information System 

2 Expansion of MIVIS 

a Integration of Route 3 North systems 

Massachusetts Turnpike Authority 

2 Improved travel information website 

City of Boston 

«2 Expansion of traffic signal system 

2 Communications network expansion/upgrade 

2 Communications infrastructure sharing with MBTA 

Massachusetts Port Authority 

2 Logan Parking Management System enhancements (pre-selling 
of parking spaces, parking space wayfinding system, Fast Lane 
payment) 

City of Brockton 

2 Traffic Operations Center 








Agency Issues and 
Priorities: 





Massachusetts Highway Department 

2 Deployment of communications infrastructure 

2 Increased traffic detector coverage 

a Increased surveillance coverage (video) 

2 Centralization of ITS functions statewide at the TOC 
Massachusetts Turnpike Authority 

2 Completion of communications infrastructure 

2 Communications infrastructure redundancy 

2 Backup facilities for emergency operation 

a Interagency coordination for emergency management 
City of Boston 

2 Expansion of CCTV deployment 

2 Remote access to TOC 

a Sharing of video with other agencies 

a Traffic and event information from other agencies 
Massachusetts Port Authority 

Traffic/incident coordination with other agencies 
En-route travel information 

Taxi availability at seaport 

Monitoring of Logan roadway traffic 

Video from adjacent CA/T roadways 

Subway coordination with MBTA 

Metropolitan District Commission 

a Traffic and event management 


a a a oO a a 





March 2005 


Page 10 





FINAL REPORT 


REGIONAL ITS ARCHITECTURE FOR METROPOLITAN BOSTON 


Exhibit 3-4: ITS Inventory — Transit 





Existing Systems and 
Ongoing Initiatives: 


Massachusetts Bay Transportation Authority 
2 Control Centers 

OCC (subway, overall hub) 

Bus Control Center 

Commuter Rail Control Centers 
2 Silver Line 

Signal priority (coordinated with BTD) 

Commuter Rail information system 
Automated Fare Collection (AFC) 
Fast Lane payment at garages 
System-wide radio upgrade 
Subway signal system upgrades 
South Station travel information kiosks 
Travel information website 
Greater Attleboro-Taunton Regional Transit Authority (GATRA) 
2 Automatic Vehicle Location (AVL) for paratransit 


Oo Oo Oo Oo Oo Oo Oo 





Planned and Proposed 
Initiatives: 


Massachusetts Bay Transportation Authority 

2 Expansion of AFC system (parking and commuter rail) 

2 Hub Station Management (subway system communication hubs) 
2 Completion of wide-area network (WAN) 

2 CCTV deployment in stations 

Brockton Area Transit (BAT): 

2 Automatic Vehicle Location (AVL) 

«2 Automated Fare Collection (AFC) 





Agency Issues and 
Priorities: 








Massachusetts Bay Transportation Authority 

<2 Customer service 

Safety and security 

CCTV deployment on vehicles 

Improved paratransit dispatching 

Signal Priority (repair of Green Line system, expansion to bus 
system for Urban Ring) 

o Expansion of Commuter Rail information system 
Other Regional Transit Authorities 

2 = Service planning 

co ~— Paratransit operations 

2 Transit security 

2 Coordination with MBTA 


Oo Oo Oo Oo 
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3.3 Basis for the Regional ITS Architecture 


The next step in the architecture development process uses the results of the needs analysis as an 
initial basis for developing the draft architecture. The ITS inventory presented in the previous 
section is the primary basis, as it holds the existing and planned elements that must be included in 
the architecture. For the purposes of the architecture, elements are classified as “existing” if their 
interface design is complete, regardless of whether the actual element is deployed. Elements are 
classified as planned if their interfaces have not yet been designed. In addition, the architecture 
considers a time horizon of up to fifteen years, with a focus on elements that are likely to be 
implemented within the next ten years. This timeframe helps ensure that the elements included in 
the architecture are relevant to the region and are not just a long-term “wish list” for the future. 


In addition to the identified inventory elements that must be included in the architecture, the 
identified needs must also be considered. The needs help determine what new elements the 
stakeholders may want to consider, and they also help determine what new interfaces between 
existing systems may be useful to consider. 


Based on the stakeholder input in the early stages of the architecture development process, four 
major themes were identified as especially important to the region: 


"Security — A common theme expressed was the new focus on security after 9/11. Many 
agencies expressed the concern that their ITS projects were being overshadowed by 
security initiatives. However, the opportunity to link ITS elements with security concerns 
also offers other opportunities for implementing ITS in the region. 


« Information Sharing — The agencies in the region have a need for better sharing of 
information among each other. This includes both real-time data such as traffic conditions 
and events, as well as more static data such as planned events and response plans. 


" Communications Infrastructure — Many agencies are in the process of building a 
communications network for operations, but many are missing portions of their network. 
Many agencies also indicated a desire to reduce their reliance on leased lines for their 
operations, thereby reducing operating costs. Opportunities exist for taking advantage of 
geographic overlap of the networks, allowing for joint implementation and cost savings. 


= Operations and Maintenance — A frequent concern expressed was the need for resources 
to support ITS. This included both financial resources as well as staffing resources required 
for operations and ongoing maintenance of ITS deployments. This illustrates the need for 
considering operations in the planning of ITS for the region. 


These four themes were considered throughout the remainder of the architecture development 


process, and specifically in the Implementation Plan, presented in Chapter 6. The outcome of this 
process is presented in the remaining chapters of this report. 
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4. ITS ARCHITECTURE 


At the core of the architecture development process is the identification of the existing and planned 
component systems and the interfaces among them. Collectively, these components and interfaces 
define the architecture. Pursuant to the Federal requirements, the Regional ITS Architecture must 
be developed using the National ITS Architecture. As such, the regional architecture builds on the 
national architecture, incorporating functions that are relevant to the region and calling out specific 
ITS elements that exist in the region. 


Building on the work of the needs analysis, which resulted in an ITS inventory and an assessment 
of regional transportation needs, an architecture input workshop was held with the Guidance 
Committee. In this two-day workshop, the participants worked together to develop the components 
of the draft architecture. This draft was subsequently distributed to the committee for review, and 
was further discussed in later meetings. Additionally, review of deliverables in the remaining steps 
in the process led to further comments on the draft architecture, and all comments received were 
addressed in the final version of the architecture. 


Turbo Architecture, a software program created by FHWA to facilitate development of regional ITS 
architectures, was used to develop the architecture. Version 2.0 of Turbo Architecture, which 
provides consistency with Version 4.0 of the National ITS Architecture, was used to develop the 
draft architecture. Following the release of the draft architecture, updated versions of the National 
ITS Architecture and Turbo Architecture were released. Consequently, the draft architecture was 
updated to Version 3.0 of Turbo Architecture before it was finalized, thus providing consistency with 
Version 5.0 of the National ITS Architecture. 


The architecture is presented in an interactive format that provides users with an accessible way to 
view the architecture. The interface allows a user to view the architecture in multiple ways and in 
varying levels of detail. The architecture is provided on the CD-ROM included in Appendix A. As 
discussed in Chapter 7, the architecture is not a static document and instead must be maintained 
so that it remains current and relevant to the region. Therefore, it should be noted that the 
architecture as presented on the CD is current as of the date of this document. The latest version 
of the architecture is accessible at http: //www.mass.gov/RegionalITSArchitecture. 





The first section of this chapter provides a summary of various elements of the Regional ITS 
Architecture. Following this summary is a guide to navigating the interactive architecture. The final 
section discusses ITS standards and their applicability. 


4.1 Summary of the Regional Architecture 


In its most basic form, the architecture is a collection of ITS elements and the interfaces between 
them. However, due to their sheer number, it is impossible in a single view to display all these 
elements and interfaces in an understandable way. The architecture therefore provides a number 
of ways of approaching this information. 


One approach is by the ITS inventory, which is a listing of the component elements. The inventory 
can be considered either by stakeholder (e.g. all elements held by MassHighway) or by function 
(e.g. all elements relating to Emergency Management). Each element in the inventory has a 
number of interfaces with other elements, both of the same stakeholder as well as of others. 
Another approach is by market packages, which group elements and interfaces by function. These 
approaches to viewing the architecture are described further in the following subsections. 
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4.1.1 STAKEHOLDERS AND ENTITIES 


In the context of the architecture, a stakeholder is any entity that holds or is responsible for an 
element in the architecture. Exhibit 4-1 presents the stakeholders holding existing or planned 
elements in the Metropolitan Boston Regional ITS Architecture. This includes public agencies that 
operate transportation systems, private organizations that have transportation-related functions, as 
well as the traveling public who interacts with the transportation network. 


The list also includes a number of “generic” stakeholders, such as “Local City/Town” or “Local 
Transit Agencies.” These are included to account for stakeholders that are not specifically called 
out in the architecture, and they serve as a placeholder for future additions. For example, consider 
a town not currently deploying ITS. This town is not included in the architecture as a stakeholder 
because it does not hold any ITS elements. However, if that town later decides to implement an 
ITS project, it can consider the generic “Local City/Town” stakeholder as an example for how this 
might be done. Once the project design is more complete, the town can then be added to the list of 
stakeholders through the architecture update process, discussed in Chapter 7. 


Exhibit 4-1: Stakeholders with Elements in the Regional ITS Architecture 














= Amtrak = Massport - Massachusetts Port Authority 

» Anderson Regional Transportation Center =" MBTA - Massachusetts Bay Transportation 

« BAT - Brockton Area Transit Authority Authority 

= _BEMA - Boston Emergency Management =» MDC - Metropolitan District Commission 
Agency = MEMA - Massachusetts Emergency 

=» BPWD - Boston Public Works Department Management Agency 

*» BTD - Boston Transportation Department = MSP - Massachusetts State Police 

"CATA - Cape Ann Transportation Authority =» MVPC - Merrimack Valley Planning 

«City of Boston Commission 

= City of Brockton =» MVRTA - Merrimack Valley Regional 

= CTPS - Central Transportation Planning Transit Authority 
Staff » NMCOG - Northern Middlesex Council of 

«Executive Office of Transportation - Office Governments 
of Transportation Planning » NOAA - National Oceanic and Atmospheric 

= Financial Institution Administration 

= GATRA - Greater Attleboro-Taunton * North of Boston Convention and Visitors 
Regional Transit Authority Bureau 

« Greater Boston Convention and Visitors * OCPC - Old Colony Planning Council 
Bureau = Other Toll Agencies 

. Greater Merrimack Valley Convention and x Private Ground Transportation Providers 
Visitors Bureau » Private Motor Carriers 

= Hospitals « Private Traveler Information Service 

« Local City/Town Providers 

. Local City/Town Shuttle Services eg Private Weather Service Providers 

« Local City/Town/County Public Safety = Rail Operators 

» Local Human Service Transit Providers « Regional Event Promoters 

= Local Media » Regional Fare Card Agencies 

« Local/Regional School Districts » _RMV - Registry of Motor Vehicles 

» _LRTA - Lowell Regional Transit Authority * SRPEDD - Southeastern Regional Planning 

= MAPC - Metropolitan Area Planning Council and Economic Development District 

» MassHighway - Massachusetts Highway « TMA - Transportation Management 
Department Associations 

» MassPike - Massachusetts Turnpike « Travelers 
Authority 
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Associated with each of these stakeholders is a number of ITS elements in the inventory. For 
example, elements in the architecture belonging to MassHighway include existing elements, such 
as its Traffic Operations Center (TOC), District Offices, and field equipment, as well as planned 
elements, such as its 511 Travel Information System. 


Exhibit 4-2 presents the ITS entities from the National ITS Architecture that have been included in 
the Metropolitan Boston Regional ITS Architecture. The types of entities included in the regional 
architecture represent only a portion of those that exist in the National ITS Architecture. The ones 
included are only those that were determined by the stakeholders to be relevant to the region. 


The entities are divided into “subsystems” and “terminators.” Subsystems are the component 
systems of the overall ITS architecture, representing the general functional areas that are 
addressed by ITS. Included within each subsystem are the real-world ITS components that are part 
of the transportation system, such as operations centers or transit vehicles. Terminators define the 
boundary of the architecture, and represent the components that interface with these subsystems. 
Terminators can include components without ITS functions that interface with ITS components, 
such as hospitals or the media, or can include ITS components that are external to the region. 


Exhibit 4-2: National ITS Architecture Entities Included in the Regional Architecture 











Subsystems: 


«Archived Data Management Subsystem 

"Commercial Vehicle Administration 

» Emergency Management 

» Emergency Vehicle Subsystem 

=» Emissions Management 

« Fleet and Freight Management 

« Information Service Provider 

« Maintenance and Construction 
Management 

« Maintenance and Construction Vehicle 

» Parking Management 

«Personal Information Access 

«Remote Traveler Support 

« Roadway Subsystem 

« Toll Administration 

«Toll Collection 

«Traffic Management 

« Transit Management 

«Transit Vehicle Subsystem 

« Vehicle 





Terminators: 


«Archived Data User Systems 

"Care Facility 

"Department of Motor Vehicles 

= Equipment Repair Facility 

= Event Promoters 

« Financial Institution 

= Intermodal Freight Depot 

=" Media 

« Multimodal Crossings 

« Multimodal Transportation Service Provider 

«Other Archives 

«Other Commercial Vehicle Administration 
Subsystem 

«Other Emergency Management 

«Other Information Service Provider 

«Other Maintenance and Construction 
Management 

«Other Maintenance and Construction Vehicle 

= Other Parking 

» Other Roadway 

«Other Toll Administration 

"Other Traffic Management 

"Other Transit Management 

«Other Vehicle 

» Rail Operations 

"Storage Facility 

« Traffic Operations Personnel 

« Transit System Operators 

«" Traveler Card 

» Wayside Equipment 

«Weather Service 
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Associated with each of these entities is a number of ITS elements in the inventory. For example, 
the Traffic Management Subsystem includes all operations centers with roadway management 
functions, including the MassHighway TOC, MassPike CA/T Operations Control Center (OCC), and 
Local City/Town Traffic Management Centers (TMCs). As an example of a terminator, the Storage 
Facility entity includes equipment depots, such as those of MassHighway, MassPike, and local 
cities and towns. 


4.1.2 MARKET PACKAGES 


Another way of approaching the architecture is by considering Market Packages. These are 
groupings of elements and interfaces that address a specific functional area (e.g. maintenance 
vehicle tracking). Market Packages represent collections of subsystems and terminators that 
exchange information to provide a specific service. A market package can cut across stakeholders, 
including all elements and interfaces required to support a function. 


Exhibit 4-3 presents the market packages for the Metropolitan Boston region, grouped by service 


area. As with the entities, not all of the market packages in the National ITS Architecture are 
included here. Instead, only the market packages that are relevant to the region are included. 


Exhibit 4-3: Regional ITS Architecture Market Packages 








Traffic Management Public Transportation 

= Network Surveillance « Transit Vehicle Tracking 

= Probe Surveillance « Transit Fixed-Route Operations 

= Surface Street Control = Demand Response Transit Operations 
= Freeway Control « Transit Passenger and Fare Management 
=" HOV Lane Management " Transit Security 

= Traffic Information Dissemination « Transit Maintenance 

= Regional Traffic Control = Multi-modal Coordination 

= Incident Management System « Transit Traveler Information 

* Electronic Toll Collection 

= Emissions Monitoring and Management Traveler Information 

= Standard Railroad Grade Crossing « Interactive Traveler Information 

= Railroad Operations Coordination « ISP Based Route Guidance 

= Parking Facility Management » Dynamic Ridesharing 


Drawbridge Management 
Commercial Vehicle Operations 


Maintenance & Consiruction Management « CV Administrative Processes 

= Maintenance and Construction Vehicle 
Tracking Emergency Management 

= Maintenance and Construction Vehicle » Emergency Response 
Maintenance = Emergency Routing 

= Road Weather Data Collection = Mayday Support 

« Weather Information Processing and = Roadway Service Patrols 
Distribution = Disaster Response and Recovery 

= Winter Maintenance = Evacuation and Reentry Management 

«" Roadway Maintenance and Construction 

= Work Zone Management Archived Data Management 

« Work Zone Safety Monitoring = ITS Data Mart 

« Maintenance and Construction Activity « ITS Virtual Data Warehouse 











Coordination 
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4.2 Navigating the Regional ITS Architecture 


This section provides an overview of the architecture as included on the CD-ROM in Appendix A. 
Exhibit 4-4 depicts the architecture homepage. Along the left side of the page are a series of 
buttons that link to different pages of the architecture. The pages to which each of these buttons 


leads are described below. 


Exhibit 4-4: Regional ITS Architecture Homepage 








Regional ITS Architecture for Metropolitan Boston 


Boston. The Commonwealth, through the Executive Office of Transportation, 
Office of Transportation Planning, has developed this architecture in 
Racion Hi cooperation with agencies and organizations involved in transportation 
Eg ROme «2 throughout the region. 
Stakeholders 


Menu | e Welcome to the homepage for the Regional ITS Architecture for Metropolitan 


Massachusetts 
Home 




















Inventory by This architecture serves a framework for transportation systems integration in the Greater Metropolitan 
Slakaholder Boston area. For the architecture development process, “Metropolitan Boston” was defined as the area 
generally within |-495, Boston’s outer circumferential highway, covering approximately 2,000 square miles, 
Inventory by and including Boston, Northern Middlesex, and Merrimack Valley MPO regions, as well as portions of the 
Entity Old Colony and Southeastern Massachusetts MPO regions. For an explanation of the Architecture 
Development Process, click here. Further information, including an Executive Summary, is available in the 


Sausage Diagram : : : i 
Project Documents section of this website. 


Market Packages 

by Functional This Regional ITS Architecture identifies the existing and planned ITS components in the region and the 

Area interfaces among them. Collectively, these components and interfaces define a framework for planning and 

Market Packages deployment of ITS in the region. This architecture has a time horizon of up to fifteen years, with particular 

by Stakeholder focus on those systems and interfaces that are likely to be implemented in the next ten years. Components 
in the architecture are classified as either “existing” or “planned.” Components classified as “existing” are 

Market Package those whose interface design is complete, regardless of whether the actual element or interface is 

Descriptions implemented. Components classified as “planned” are those whose interfaces have not yet been designed. 


Equipment 
ai ge This architecture is a valuable tool for those who plan, design, implement, and operate intelligent 
ge transportation systems. Moreover, it provides the basis for satisfying federal architecture consistency 
Descriptions 3 . snl : : 
- requirements for ITS projects. It is important to recognize, however, that an ITS project, like any other 
Bursa tle da) transportation project, is developed within the region’s existing transportation planning process. As such, 
Descriptions ITS project proponents must still work with their regional planning partners and follow the established 


Project regional planning process in developing their ITS project. 


i serch While the architecture has relevance throughout the project development process, this website focuses on 
Feedback the initial review for architecture consistency in the early stages of the process. The following links provide 
background and guidance on using the website for this purpose: 


« Navigating the website 





« Regulatory requirements 





¢ Is your project an ITS project? 








« Using this site to conduct your initial review 
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Massachusetts Home: This button takes the user to the homepage for the Massachusetts 
Regional ITS Architectures 


Region Home: This button returns the user to the Metropolitan Boston homepage. 


Stakeholders: This page presents the full list of regional stakeholders, along with descriptions 
for each. 


Inventory by Stakeholder: This page presents the inventory of ITS elements, arranged by 
stakeholder. This allows all the elements held by a single stakeholder to be viewed 
simultaneously. Clicking on an element name links to a detail page for that element that 
provides more information, including a listing of all interfacing elements. 


Inventory by Entity: This page presents the inventory of ITS elements, arranged by entity 
(subsystems and terminators). This allows all elements with related functions to be viewed 
simultaneously. Clicking on an element name links to a detail page for that element. 


Sausage Diagram: The Architecture Interconnect Diagram (a.k.a. the “Sausage Diagram’) 
illustrates the ITS subsystems and terminators present in the Regional ITS Architecture. Along 
the perimeter of the diagram are tables for each subsystem and terminator, identifying the 
specific regional instances of each subsystem or terminator. 


Market Package Descriptions: This page presents descriptions for each of the market 
packages that are included in the architecture. 


Market Packages by Functional Area: This page presents a table of the relevant market 
packages for the region. Clicking on the market package number links to a series of customized 
diagrams for each package. These market package diagrams illustrate the elements and 
interfaces that are contained in that market package. Each subsystem or terminator in a market 
package diagram is labeled with both its generic National ITS Architecture name and the name 
of the local stakeholder instance that participates in the customized market package. In this way 
the market package identifies the information exchange (using architecture flows) between 
specific elements in the region to achieve a particular service or set of services. 


Market Packages by Stakeholder: This page presents a list of the relevant market packages 
for each stakeholder. Clicking on a market package links to the customized diagram in which 
that stakeholder’s element appears. 


Equipment Package Descriptions: This page presents descriptions of the relevant equipment 
packages from the architecture. Equipment packages represent specific functions carried out by 
the subsystems. 


Architecture Flow Descriptions: This page presents descriptions of the relevant architecture 
flows from the architecture. Architecture flows appear in the interface diagrams, indicating what 
information is exchanged between two different components. 


Project Documents: This page contains documents generated through the architecture 
development process, including the deliverables reviewed by the Guidance Committee. 


Feedback: This button launches the user’s email application, allowing the user to send 
comments to the project team. 
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4.3 Applicable Standards 


Standards are technical specifications established by consensus that provide rules, guidelines or 
characteristics for data interfaces. ITS standards, in particular, govern the interfaces of 
transportation system components. They contain and specify the technical details on how to build 
and integrate ITS systems and components in a way that facilitates interoperability. Standards 
provide the technical detail that enables the design and deployment of an integrated ITS system. 
Standards allow different systems to speak to each other in a common language, using common 
data elements, well-defined data structures or “messages,” and well-understood protocols or rules 
for data exchange and sharing. 


ITS standards are being developed by several working groups composed of public and private 
sector stakeholders within Standards Development Organizations (SDOs). The process is partially 
supported by the US Department of Transportation. There are seven SDOs actively participating in 
ITS standards development activities: 


» AASHTO (American Association of State Highway and Transportation Officials) 
= ANSI (American National Standards Institute) 

= ASTM (American Society for Testing and Materials) 

= EEE (Institute of Electrical and Electronics Engineers) 

= ITE (Institute of Transportation Engineers) 

=» NEMA (National Electrical Manufacturers Association) 

"SAE (Society of Automotive Engineers) 


There are approximately 80 standards that are unique to ITS applications. Many of these 80 
standards have already passed through the development process, and have been approved and 
published by the applicable SDOs. Others are progressing and will be approved soon. 


To date, USDOT has not yet adopted specific ITS standards. However, in TEA-21, Congress 
required the USDOT to “ensure that ITS projects carried out using funds made available from the 
Highway Trust Fund... conform to the national architecture, applicable standards, or provisional 
standards and protocols.” Therefore, it is anticipated that ITS standards will eventually be adopted 
by USDOT and that their use will be made mandatory. In the interim, it makes good sense to utilize 
approved ITS standards in system design and implementation regardless of their being mandatory. 
This approach has little risk and facilitates future integration opportunities. 


The Regional ITS Architecture, therefore, does not recommend a specific standard for each 
interface. Because standards continue to evolve and have not yet been adopted, it would be 
premature for the architecture to dictate what standards to use when an initiative is only in the 
conceptual stage. Instead, the architecture presents the standards that are relevant for each 
architecture flow, with the expectation that they will be considered in the project design. These 
standards can be found in the architecture on each architecture flow detail page, which contains a 
description of the architecture flow and a list of relevant communications, message, and data 
standards. 
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5. OPERATIONAL CONCEPT 


In the initial steps of the architecture development process, stakeholder interviews, workshops, and 
working sessions determined the technical components of the architecture. This process 
developed an architecture that defines the existing and planned component systems, as well as the 
interfaces among them. The architecture provides a vision of an integrated transportation system 
that involves numerous agencies. It is critical, therefore, to address the many interagency 
relationships needed to plan, operate, and maintain those systems. For this reason, the architecture 
development process includes the creation of an operational concept. 


The operational concept focuses on the institutional aspects of the Regional ITS Architecture. It 
defines the relationships among the organizations in the region required for the deployment and 
operation of an integrated transportation system. The purpose of the operational concept is to 
define the roles and responsibilities of the stakeholders in the implementation and operation of the 
systems that make up the architecture. 


The first section of this chapter, Operational Coordination, discusses the different levels of 
interaction and types of information exchange that may be required for operation of interagency 
interfaces. The second section, Interagency Interfaces, presents a detailed operational concept for 
each of the interagency interfaces that the architecture identifies. Finally, the third section, 
Institutional Coordination, covers the key institutional issues, including interagency agreements. 


5.1 Operational Coordination 


ITS initiatives that involve cross-jurisdictional relationships will require a detailed operational 
concept. In some cases, multiple agencies will need to form relationships with each other to define 
specific roles and responsibilities for the deployment and operation of the system. 


Operational relationships between agencies are defined by two main components: 1) the 
roles/responsibilities of each agency in the relationship, and 2) the types of information that each 
agency shares. Exhibit 5-1 identifies seven types of agency-to-agency relationships, spanning the 
range of potential institutional interactions that might occur between two organizations in the 
operation and maintenance of an ITS application. The exhibit lists the relationships from lowest to 
highest level of interaction and provides definitions and examples for each of the identified 
relationships. 


Each of these relationships implies some exchange of information between two agencies. The 
information being exchanged can be classified into one of six types of information flows. Exhibit 5-2 
provides definitions and examples for these information flows. 


As these exhibits illustrate, the extent of interaction and information exchange between agencies 
can vary greatly. Relationships can vary from consultation and cooperation, where electronic 
information is not exchanged, to full transfer of operational responsibility. The extent of the 
interaction will depend on many factors, including the nature of the information being exchanged, 
the technical capabilities of the agencies, and the institutional relationships already in place. A 
different relationship may therefore be appropriate for each particular interagency interface. The 
next section discusses all of the interagency interfaces in the architecture and proposes an 
operational concept for each, based on the relationships and information flows identified by the 
participants. 
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Exhibit 5-1: Agency-to-Agency Relationships 





Relationship 


Definition 


Example 





Consultation 


One party confers with another party, in 
accordance with an established process, about 
an anticipated action and then keeps that party 
informed about the actions taken. Information is 
exchanged through traditional means of 
communication, such as phone or face-to-face 
meetings. 


Agency A provides 
information on activities to 
Agency B. 





Cooperation 


The parties involved in carrying out the 
planning, project development and operations 
processes work together to achieve common 
goals or objectives. Information is exchanged 
through traditional means of communication. 


Both agencies cooperate in 
the development and 
execution of common plans, 
projects, and operational 
procedures. 





Information 
Sharing 


The electronic exchange of data and device 
status information between parties for the 
purposes of coordinated operations, planning, 
and analysis. 


Agency A will provide status, 
data, and/or video information 
from Agency A’s field devices 
(e.g. detectors) to Agency B. 





Control Sharing 


The ability, through operational agreements, to 
allow for one party to control another party’s 
field devices to properly respond to incident, 
event, weather, or traffic conditions. 


Agency A is allowed by 
Agency B to control the 
Agency B’s field devices (e.g. 
VMS, select signal timing 
patterns) for specified defined 
occurrences. 





Operational 
Responsibility 
Shifted 


One party operates the field equipment of a 
second party on a full time basis. 


Agency A will operate the 
field devices of Agency B 
(e.g. County operates a City’s 
traffic signals but the City is 
responsible for maintenance 
and repairs.) 





Maintenance 
Responsibility 


One party maintains the field equipment of a 
second party. 


Agency A maintains the field 
devices of Agency B, but the 
Agency B is responsible for 











maintenance. 





ebilicd operations. 

el See enor rhe Fed agency A apeates an 
Responsibility Seance and SF ARE Gnd sisi ane maintains the field devices of 
Shifted P P geney. Agency B. 
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Exhibit 5-2: Information Flow Definitions 


























er aten Definition Example 
Flow 
Data The dissemination of raw, unprocessed data gathered from | Agency A sends 
one party’s field devices or systems to another party. Data | data from its field 
can include, but is not limited to, traffic, weather, parking, devices to Agency B. 
transit data, etc. Video images are not included in this 
information flow. 
Video The dissemination of live video and still images from one Agency A sends live 
party’s field camera’s to another party video and still 
images to Agency B. 
Event The dissemination of event/incident information or other Agency A sends 
Information processed data from one party to another party. processed data to 
Agency B. 
Device The ability for one party to monitor another party’s field Agency A sends 
Status devices, and to receive such information as current signal status information on 
timing/response plan, current message sets, etc. its devices to 
Agency B. 
Request The ability for one party to solicit either information or a Agency A requests 
command change, such as Variable Message Sign (VMS) information or action 
or signal timing changes, from another party. from Agency B. 
Control The ability for one party to control another party’s field Agency A issues 





devices. Control can include but is not limited to, changing 
VMS messages, changing traffic signal timings, camera 
control, etc. 





control instruction to 
Agency B’s field 
devices. 





5.2 Interagency Interfaces 


Of the hundreds of interfaces included in the architecture, the ones considered in the Operational 
Concept are those that involve multiple agencies. The interagency interfaces called for in the 

Regional ITS Architecture are identified and defined in this section. The interfaces are addressed 
within the following categories: 


= Roadway Management 

= Transit Management 

=» Emergency Management 
= Data Archives 

= Electronic Fare Payment 
«Electronic Toll Collection 


It should be noted that these categories are not the same as the functional areas used in the 
“Market Packages by Functional Area” section of the architecture and as defined by the National 
ITS Architecture. Instead, these categories have been defined in order to help in the discussion of 
the large number of interfaces. They do not directly correspond to the market package functional 
areas because the interfaces of interest do not necessarily fall under a single market package or 
even a single functional area. For example, the interface supporting the provision of traffic 
information from a traffic management center to a bus control center falls under both the “Traffic 
Information Dissemination” and “Transit Fixed-Route Operations” market packages. The interface 
might also support the provision of traffic signal priority for buses, which would fall under both the 
“Transit Fixed-Route Operations” market package and the “Regional Traffic Control” market 


package. 
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To reduce this overlap, the following subsections group the interfaces under the more basic 
categories defined above. Within each category, operational concepts have been defined for either 
individual interfaces or groups of similar interfaces. The intent of the discussion of each interface is 
to outline how the interface will be addressed by the two agencies, including what information will 
be exchanged and how this exchange will occur. Defining these interfaces serves as the initial step 
in the development of agreements between the interfacing agencies, as it starts the process of 
identifying the content and the issues that must be addressed in the interagency agreements. 


5.2.1 ROADWAY MANAGEMENT 


Exhibit 5-3 illustrates the interagency interfaces required to support regional roadway management 
functions. There are numerous interfaces between the various traffic management centers in the 
region. An additional set of interfaces exists between each of the traffic management centers and 
private traveler information service providers to support traveler information functions. 


Exhibit 5-3: Interagency Interfaces - Roadway Management 
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Service Providers 





Each of these interfaces is addressed by an operational concept. The following operational 
concepts are defined for Roadway Management: 


= Center-to-Center 
o MassHighway and MassPike 
2 BTD and MassHighway 
2 BTD and MassPike 
2 BTD and Massport 
2 Massport and MassHighway 
a _Massport and MassPike 
a ~=©Other 


« Traffic Signal Operation 
=» Private Traveler Information 


Note that a separate Center-to-Center operational concept is defined between each of the major 
control centers in the region. This is due to the specialized nature of the major control centers in 
the region (i.e. those of BTD, MassHighway, MassPike, and Massport) and the need to recognize 
preexisting relationships established among them. These operational concepts are presented in 
Exhibit 5-4 through Exhibit 5-12. 
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Exhibit 5-4: Operational Concept: Roadway Management — Center-to-Center (MassHighway and MassPike) 





Operational Concept: 


Center-to-Center (MassHighway and MassPike) 





Functional Area: 








Roadway Management 


The interface between MassHighway and MassPike will be implemented between their respective traffic control 
centers, namely the MassHighway Traffic Operations Center and the MassPike CA/T Operations Control 
Center. The interface will support a number of functions, including traffic management, maintenance 
management, and traveler information (e.g. the 511 Travel Information System). 





Interfacing Agencies: 


» MassHighway and MassPike 








Information Flow 


Relationship 





Data: 


Information Sharing: Traffic data, including flows and speeds calculated at vehicle 
detector stations, will be exchanged between the two control centers. This will be 
achieved by a link between the traffic management systems at both facilities. An 
operator at the MassHighway TOC, for example, will be able to view sensor output 
from selected CA/T traffic detectors on his/her control console. 





Video: 


Information Sharing: Video images will be exchanged between the two control centers 
to allow operator viewing of select CCTV cameras from the other agency. 

Pan/til/zoom control of the camera will remain in the control of the agency owning the 
camera, but requests for camera repositioning may be made via voice communications 
(e.g. phone or radio). 





Event Information: 


Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two control centers through a shared 
connection to a centralized database. Each agency will enter event information for 
roadways within its jurisdiction into the database. For MassHighway, the central traffic 
management system software will automatically send event information to the 
database. For the MassPike, entering of information may be manual, by means of a 
web-based interface, or automatic, by means of an automated process developed for 
its traffic management software. Similarly, event information will be received by each 
traffic management center either through an automated link with the central software or 
through operator monitoring of a web-based interface. 





Device Status: 


Consultation: Exchange of device status information, including incident response 
measures such as VMS messages, will occur via voice communications. Coordination 
via phone or radio will be essential when incident response on one agency’s roadways 
will affect operations on the other agency’s roadways. Automated exchange of device 
status information, such as the ability to monitor messages displayed on the other 
agency’s VMSs, is recommended for future implementation. 














Request: | Consultation: Data exchange will be automatic and thus not require requests between 
agencies. Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. All other requests, such as placement of messages 
on the other agency’s VMSs, will also be made via voice communications. 

Control: | Independent: Direct control of the other agency’s field equipment will not be permitted. 


All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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Exhibit 5-5: Operational Concept: Roadway Management — Center-to-Center (BTD and MassHighway) 





Operational Concept: | Center-to-Center (BTD and MassHighway) 








Functional Area: Roadway Management 





The interface between BTD and MassHighway will be implemented between their respective traffic control 
centers, namely the BTD Traffic Management Center and the MassHighway Traffic Operations Center. The 
interface will support a number of functions, including traffic management, maintenance management, and 
traveler information (e.g. the 511 Travel Information System). Some of the interfaces covered by this 
operational concept already exist, such as the interface to exchange video through the Massachusetts 
Interagency Video Information System (MIVIS). 





Interfacing Agencies: |= BID and MassHighway 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Information Sharing: As part of the Massachusetts Interagency Video Information 
System, video images are exchanged between the two control centers, allowing 
operator viewing of select CCTV cameras from the other agency. Pan/tilt/zoom control 
of the camera remains in the control of the agency owning the camera, but requests for 
camera repositioning can be made via voice communications (e.g. phone or radio). 





Event Information: | Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two control centers through a shared 
connection to a centralized database. Each agency will enter event information for 
roadways within its jurisdiction into the database. For MassHighway, the central 
software will automatically send event information to the database. For BTD, entering 
of information may be manual, by means of a web-based interface, or automatic, by 
means of an automated process developed for its traffic management software. 
Similarly, event information will be received by each traffic management center either 
through an automated link with the central software or through operator monitoring of a 
web-based interface. 





Device Status: | Consultation: Exchange of device status information, including incident response 
measures such as VMS messages, will occur via voice communications. Coordination 
via phone or radio will be essential when incident response on one agency’s roadways 
will affect operations on the other agency’s roadways. Automated exchange of device 
status information, such as the ability to monitor messages displayed on the other 
agency’s VMSs, is recommended for future implementation. 





Request: | Consultation: Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. All other requests, such as placement of messages 
on the other agency’s VMSs, will also be made via voice communications. 





Control: | Independent: Direct control of the other agency’s field equipment will not be permitted. 
All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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Exhibit 5-6: Operational Concept: Roadway Management — Center-to-Center (BTD and MassPike) 





Operational Concept: | Center-to-Center (BTD and MassPike) 
Functional Area: Roadway Management 











The interface between BTD and MassPike will be implemented between their respective traffic control centers, 
namely the BTD Traffic Management Center and the MassPike CA/T Operations Control Center. 





Interfacing Agencies: |= BTD and MassPike 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Information Sharing: Video images will be exchanged between the two control centers 
to allow operator viewing of select CCTV cameras from the other agency. 

Pan/til/zoom control of the camera will remain in the control of the agency owning the 
camera, but requests for camera repositioning may be made via voice communications 
(e.g. phone or radio). Currently, some CA/T cameras are viewable at the TMC as 
described. 





Event Information: | Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two control centers through a shared 
connection to a centralized database. Each agency will enter event information for 
roadways within its jurisdiction into the database. Entering of information may be 
manual, by means of a web-based interface, or automatic, by means of an automated 
process developed for the traffic management software at each control center. 
Similarly, event information will be received by each traffic management center either 
through an automated link with the central software or through operator monitoring of a 
web-based interface. 





Device Status: | Consultation: Exchange of device status information, including incident response 
measures such as VMS messages, will occur via voice communications. Coordination 
via phone or radio will be essential when incident response on one agency’s roadways 
will affect operations on the other agency’s roadways. Automated exchange of device 
status information, such as the ability to monitor messages displayed on the other 
agency’s VMSs, is recommended for future implementation. 





Request: | Coordination: Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. All other requests, such as placement of messages 
on the other agency’s VMSs, will also be made via voice communications. 





Control: | Independent: Direct control of the other agency’s field equipment will not be permitted. 
All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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Exhibit 5-7: Operational Concept: Roadway Management - Center-to-Center (BTD and Massport) 





Operational Concept: 


Center-to-Center (BTD and Massport) 





Functional Area: 








Roadway Management 


The interface between BTD and Massport will be implemented between their respective traffic control centers, 
namely the BTD Traffic Management Center and the Massport Landside Operations Control Center. 





Interfacing Agencies: 


" BTD and Massport 








Information Flow 


Relationship 





Data: 





Video: 


Not applicable. 


Information Sharing: Video images will be exchanged between the two control centers 
to allow operator viewing of select CCTV cameras from the other agency. 

Pan/til/zoom control of the camera will remain in the control of the agency owning the 
camera, but requests for camera repositioning may be made via voice communications 
(e.g. phone or radio). 





Event Information: 


Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two control centers through a shared 
connection to a centralized database. Each agency will enter event information for 
roadways within its jurisdiction into the database. Entering of information may be 
manual, by means of a web-based interface, or automatic, by means of an automated 
process developed for the traffic management software at each control center. 
Similarly, event information will be received by each traffic management center either 
through an automated link with the central software or through operator monitoring of a 
web-based interface. 





Device Status: 


Consultation: Exchange of device status information, including incident response 
measures such as VMS messages, will occur via voice communications. Coordination 
via phone or radio will be essential when incident response on one agency’s roadways 
will affect operations on the other agency’s roadways. Automated exchange of device 
status information, such as the ability to monitor messages displayed on the other 
agency’s VMSs, is recommended for future implementation. 





Request: 


Control: 





Coordination: Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. All other requests, such as placement of messages 
on the other agency’s VMSs, will also be made via voice communications. 








Independent: Direct control of the other agency’s field equipment will not be permitted. 
All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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Exhibit 5-8: Operational Concept: Roadway Management — Center-to-Center (Massport and MassHighway) 





Operational Concept: 


Center-to-Center (Massport and MassHighway) 





Functional Area: 








Roadway Management 


The interface between Massport and MassHighway will be implemented between their respective traffic control 
centers, namely the Massport Landside Operations Control Center and the MassHighway Traffic Operations 
Center. The interface will support a number of functions, including traffic management, maintenance 
management, and traveler information (e.g. the 511 Travel Information System). 





Interfacing Agencies: 


« Massport and MassHighway 








Information Flow 


Relationship 





Data: 


Not applicable. 





Video: 


Information Sharing: Video images will be exchanged between the two control centers 
to allow operator viewing of select CCTV cameras from the other agency. 

Pan/til/zoom control of the camera will remain in the control of the agency owning the 
camera, but requests for camera repositioning may be made via voice communications 
(e.g. phone or radio). 





Event Information: 


Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two control centers through a shared 
connection to a centralized database. Each agency will enter event information for 
roadways within its jurisdiction into the database. For MassHighway, the central 
software will automatically send event information to the database. For Massport, 
entering of information may be manual, by means of a web-based interface, or 
automatic, by means of an automated process developed for its traffic management 
software. Similarly, event information will be received by each traffic management 
center either through an automated link with the central software or through operator 
monitoring of a web-based interface. 





Device Status: 


Consultation: Exchange of device status information, including incident response 
measures such as VMS messages, will occur via voice communications. Coordination 
via phone or radio will be essential when incident response on one agency’s roadways 
will affect operations on the other agency’s roadways. Automated exchange of device 
status information, such as the ability to monitor messages displayed on the other 
agency’s VMSs, is recommended for future implementation. 





Request: 


Coordination: Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. All other requests, such as placement of messages 
on the other agency’s VMSs, will also be made via voice communications. 





Control: 








Independent: Direct control of the other agency’s field equipment will not be permitted. 
All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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Exhibit 5-9: Operational Concept: Roadway Management - Center-to-Center (Massport and MassPike) 





Operational Concept: | Center-to-Center (Massport and MassPike) 
Functional Area: Roadway Management 











The interface between Massport and MassPike will be implemented between their respective traffic control 
centers, namely the Massport Landside Operations Control Center and the MassPike CA/T Operations Control 
Center. 





Interfacing Agencies: | = Massport and MassPike 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Information Sharing: Video images will be exchanged between the two control centers 
to allow operator viewing of select CCTV cameras from the other agency. 

Pan/til/zoom control of the camera will remain in the control of the agency owning the 
camera, but requests for camera repositioning may be made via voice communications 
(e.g. phone or radio). 





Event Information: | Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two control centers through a shared 
connection to a centralized database. Each agency will enter event information for 
roadways within its jurisdiction into the database. Entering of information may be 
manual, by means of a web-based interface, or automatic, by means of an automated 
process developed for the traffic management software at each control center. 
Similarly, event information will be received by each traffic management center either 
through an automated link with the central software or through operator monitoring of a 
web-based interface. 





Device Status: | Consultation: Exchange of device status information, including incident response 
measures such as VMS messages, will occur via voice communications. Coordination 
via phone or radio will be essential when incident response on one agency’s roadways 
will affect operations on the other agency’s roadways. Automated exchange of device 
status information, such as the ability to monitor messages displayed on the other 
agency’s VMSs, is recommended for future implementation. 





Request: | Coordination: Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. All other requests, such as placement of messages 
on the other agency’s VMSs, will also be made via voice communications. 





Control: | Independent: Direct control of the other agency’s field equipment will not be permitted. 
All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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Exhibit 5-10: Operational Concept: Roadway Management — Center-to-Center (Other) 





Operational Concept: | Center-to-Center (Other) 








Functional Area: Roadway Management 





This operational concept covers interfaces between major traffic control centers and smaller dispatch/operation 
centers (such as those of the MDC and some local cities/towns). The interfaces included in this operational 
concept will support a number of functions, including traffic management, maintenance management, and 
traveler information (e.g. the 511 Travel Information System). 





Local Cities/Towns and BTD 

Local Cities/Towns and MassHighway 
Local Cities/Towns and MassPike 

Local Cities/Towns and Massport 

City of Brockton and Local Cities/Towns 
City of Brockton and MassHighway 
MDC and Local Cities/Towns 

MDC and MassHighway 

MDC and MassPike 

MDC and Massport 


Interfacing Agencies: 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Information Sharing: lf the smaller operation has capability for video, video images will 
be exchanged between the two control centers to allow operator viewing of select 
CCTV cameras from the other agency. Pan/tilt/zoom control of the camera will remain 
in the control of the agency owning the camera, but requests for camera repositioning 
may be made via voice communications (e.g. phone or radio). 





Event Information: | Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two centers through a shared connection 
to a centralized database. Each agency will enter event information into the database 
for roadways within its jurisdiction. Entering of information may be manual, by means 
of a web-based interface, or automatic, by means of an automated process developed 
for the central software (if applicable). Similarly, event information will be received by 
each traffic management center either through operator monitoring of a web-based 
interface or through an automated link with the central software. 





Device Status: | Consultation: Exchange of device status information, including incident response 
measures such as VMS messages, will occur via voice communications. Coordination 
via phone or radio will be essential when incident response on one agency’s roadways 
will affect operations on the other agency’s roadways. Automated exchange of device 
status information, such as the ability to monitor messages displayed on the other 
agency’s VMSs, is recommended for future implementation. 





Request: | Coordination: Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. All other requests, such as placement of messages 
on the other agency’s VMSs, will also be made via voice communications. 





Control: | Independent: Direct control of the other agency’s field equipment will not be permitted. 
All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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Exhibit 5-11: Operational Concept: Roadway Management - Traffic Signal Operation 





Operational Concept: | Traffic Signal Operation 








Functional Area: Roadway Management 





This operational concept applies to the interface between BTD and MDC. This interface is implemented 
between the BTD Traffic Management Center and select MDC traffic signal controllers within the City of 
Boston. 





Interfacing Agencies: |= BTID andMDC 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Not applicable. 





Event Information: | Not applicable. 





Device Status: | Not applicable. 





Request: | Not applicable. 





Control: | Operational Responsibility Shifted: Traffic signals and signal controllers owned by 
MDC will be monitored and operated by BTD as part of the central traffic signal system 
at the Traffic Management Center. MDC will be responsible for maintenance of all field 
equipment, but BTD will have full operational control. 
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Exhibit 5-12: Operational Concept: Roadway Management - Private Traveler Information 





Operational Concept: 


Private Traveler Information 





Functional Area: 








This operational concept applies to the interfaces between Private Traveler Information Service Providers 
control centers and traffic management agency control centers. 


Roadway Management 


3 





Interfacing Agencies: 


Private Traveler Information Service Providers and BTD 

« Private Traveler Information Service Providers and City of Brockton 

= Private Traveler Information Service Providers and Local Cities/Towns 
« Private Traveler Information Service Providers and MassHighway 

= Private Traveler Information Service Providers and MassPike 

« Private Traveler Information Service Providers and Massport 








Information Flow 


Relationship 





Data: 


Not applicable. 





Video: 


Information Sharing: Video images will be exchanged between the two control centers 
to allow operator viewing of select CCTV cameras from the other agency. 

Pan/til/zoom control of the camera will remain in the control of the agency owning the 
camera, but requests for camera repositioning may be made via voice communications 
(e.g. phone or radio). This interface already exists from SmartRoutes, a private 
traveler information service provider, to MassHighway and to BTD through the 
Massachusetts Interagency Video Information System (MIVIS). 





Event Information: 


Information Sharing: Event information, such as accident, delay, and construction 
information, will be exchanged between the two control centers through a shared 
connection to a centralized database. Each agency will enter event information for 
roadways within its jurisdiction or coverage area into the database. Entering of 
information may be manual, by means of a web-based interface, or automatic, by 
means of an automated process developed for the central software at each control 
center. Similarly, event information will be received by each control center either 
through an automated link with the central software or through operator monitoring of a 
web-based interface. 





Device Status: 


Independent: No exchange of device status information is planned. However, 
automated exchange of device status information, such as VMS states, is 
recommended for future implementation, so that information provided by the private 
service provider is consistent with agency messages. 





Request: 


Coordination: Requests for CCTV camera repositioning, as mentioned above, will be 
made via voice communications. 





Control: 








Independent: Direct control of the other agency’s field equipment will not be permitted. 
All control will remain with the agency that owns the equipment. Indirect control is 
possible via requests to the other agency, as discussed above. 
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5.2.2 TRANSIT MANAGEMENT 


Exhibit 5-13 illustrates the interagency interfaces required to support regional transit management 
functions. These interfaces include center-to-center interfaces among transit control centers, 
interfaces between transit control centers and traffic control centers, and interfaces with private 
travel information service providers. 


Exhibit 5-13: Interagency Interfaces — Transit Management 


Traffic Management 
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Each of these interfaces is addressed by one of the following operational concepts: 


= Center-to-Center 

= Traffic Coordination 

"Traffic Coordination and Signal Priority 
" Grade Crossings 

= Private Traveler Information 


These operational concepts are presented in Exhibit 5-14 through Exhibit 5-18, respectively. 
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Exhibit 5-14: Operational Concept: Transit Management — Center-to-Center 





Operational Concept: 


Center-to-Center 





Functional Area: 








Transit Management 


This operational concept applies to the interfaces among the various transit operations control centers. The 
interfaces included in this operational concept will support transit management and traveler information 











functions. 

Interfacing Agencies: | = MBTA and Amtrak « BAT and CATA 
" _MBTA and Local City/Town Shuttle Services « BAT and GATRA 
« _MBTA and Local Human Service Transit Providers " BAT andLRTA 
«= MBTA and Massport (transit) » BAT and MVRTA 
" MBTA and Private Ground Transportation Providers = CATAand GATRA 
» MBTA and BAT " CATA and LRTA 
« MBTA and CATA "CATA and MVRTA 
« MBTA and GATRA " GATRA and LRTA 
" MBTA and LRTA "  GATRA and MVRTA 
" MBTA and MVRTA » LRTA and MVRTA 
« MBTA and TMAs 

Information Flow | Relationship 





Data: 


Not applicable. 





Video: 


Not applicable. 





Event Information: 


Information Sharing: Event information such as service updates will be exchanged 
through a shared connection to a centralized database. Entering of information may 
be manual, by means of a web-based interface, or automatic, by means of an 
automated process developed for the central software at each control center. Event 
information will be received by each control center either through an automated link 
with the central software or through operator monitoring of a web-based interface. 


Consultation: Exchange of response status information, including incident response 
measures such as service modifications, will occur via voice communications. 
Coordination via phone or radio will be essential when incident response by one 
agency affects operations by the other. 





Device Status: 


Not applicable. 














Request: | Coordination: Requests, such as those for service modifications such as vehicle 
holding or rerouting, will be made via voice communications. An automated system 
and protocol is recommended for situations where requests are frequent. 

Control: | Not applicable. 
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Exhibit 5-15: Operational Concept: Transit Management — Traffic Coordination 





Operational Concept: 


Traffic Coordination 





Functional Area: 





Transit Management 





Information System). 


This operational concept applies to the interfaces between transit operations control centers and traffic 
management control centers. The interfaces included in this operational concept will support a number of 
functions, including traffic management, transit management, and traveler information (e.g. the 511 Travel 





Interfacing Agencies: 


. BTD and Massport (transit) 7 MassHighway and Local Human 

=  BTD and Private Ground Service Transit Providers 
Transportation Providers =» MassHighway and Massport (transit) 

» City of Brockton and BAT » MassHighway and MBTA 

« Local Cities/Towns (traffic) and Local " MassHighway and Private Ground 
City/Town Shuttle Services Transportation Providers 


« Local Cities/Towns (traffic) and Local MassHighway and BAT 


Human Service Transit Providers « MassHighway and CATA 

« Local Cities/Towns (traffic) and « MassHighway and GATRA 
Massport (transit) =» MassHighway and LRTA 

= Local Cities/Towns (traffic) and « MassHighway and MVRTA 
Private Ground Trans. » MassHighway and TMAs 

= Massport (traffic) and MBTA = MassPike and Massport (transit) 

« MassHighway and Local City/Town =" MassPike and Private Ground 
Shuttle Services Transportation Providers 








Information Flow 


Relationship 





Data: 





Video: 


Not applicable. 


Information Sharing: The transit agency will have access to video feeds from select 
traffic cameras to support dispatching operations. Pan/tilt/zoom control of the 
camera will remain in the control of the traffic operations center, but requests for 
camera repositioning by the transit agency may be made via voice communications 
(e.g. phone or radio). This interface already exists between MassHighway and the 
MBTA through the Massachusetts Interagency Video Information System (MIVIS). 





Event Information: 


Information Sharing: Event information from the traffic operations center, such as 
accident, delay, and construction information, will be provided to the transit agency 
through a shared connection to a centralized database. The traffic operations center 
will enter event information for roadways within its jurisdiction into the database. 
Entering of information may be manual, by means of a web-based interface, or 
automatic, by means of an automated process developed for the traffic management 
software at the control center. The transit agency will receive event information 
through operator monitoring of a web-based interface. 


Consultation: Exchange of response status information, including incident response 
measures such as street closures or service modifications, will occur via voice 
communications. Coordination via phone or radio will be essential when incident 
response by the traffic operations center affects operations by the transit agency, 
and vice versa. 





Device Status: 


Not applicable. 














Request: | Consultation: Requests from the transit agency to the traffic operations center for 
CCTV camera repositioning, as discussed above, will be made via voice 
communications. 

Control: | Independent: Direct control of roadway field equipment will not be permitted, as all 


control will remain with the traffic operations center. Indirect control by the transit 
agency is possible via requests to the traffic operations center, as discussed above. 
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Exhibit 5-16: Operational Concept: Transit Management — Traffic Coordination and Signal Priority 





Operational Concept: 


Traffic Coordination and Signal Priority 





Functional Area: 








Interfacing Agencies: 


Transit Management 


As with the “Traffic Coordination” operational concept described in Exhibit 5-15, this operational concept 
applies to the interfaces between transit operations control centers and traffic management control centers. 
However, this operational concept also includes the provision of signal priority for transit vehicles. 


BTD and MBTA 

Local Cities/Towns (traffic) and MBTA 
Local Cities/Towns (traffic) and BAT 
Local Cities/Towns (traffic) and CATA 
Local Cities/Towns (traffic) and GATRA 
Local Cities/Towns (traffic) and LRTA 
Local Cities/Towns (traffic) and MVRTA 
Local Cities/Towns (traffic) and TMAs 








Information Flow 


Relationship 





Data: 


Not applicable. 





Video: 


Information Sharing: The transit agency will have access to video feeds from select 
traffic cameras to support dispatching operations. Pan/tilt/zoom control of the camera 
will remain in the control of the traffic operations center, but requests for camera 
repositioning by the transit agency may be made via voice communications (e.g. 
phone or radio). 





Event Information: 


Information Sharing: Event information from the traffic operations center, such as 
accident, delay, and construction information, will be provided to the transit agency 
through a shared connection to a centralized database. The traffic operations center 
will enter event information for roadways within its jurisdiction into the database. 
Entering of information may be manual, by means of a web-based interface, or 
automatic, by means of an automated process developed for the traffic management 
software at each control center. The transit agency will receive event information 
through operator monitoring of a web-based interface. 


Consultation: Exchange of response status information, including incident response 
measures such as street closures or service modifications, will occur via voice 
communications. Coordination via phone or radio will be essential when incident 
response by the traffic operations center affects operations by the transit agency, and 
vice versa. 





Device Status: 


Information Sharing: Relevant status information for field devices will include traffic 
signal status and information about transit priority calls. Field device status will be 
reported to the transit authority from the traffic management center by means of a 

direct connection between the central systems. 





Request: 


Information Sharing: Requests for traffic signal priority for buses or light rail vehicles 
will be made to the traffic signal system controlled by the traffic operations center. This 
may occur locally at the signal controller or through a request to the central system. If 
the request is to the central system, the traffic operations center will make the 
determination of whether or not to grant priority. 


Consultation: Requests from the transit agency to the traffic operations center for 
CCTV camera repositioning, as mentioned above, will be made via voice 
communications. 





Control: 








Independent: Direct control of roadway field equipment will not be permitted, as all 
control will remain with the traffic operations center. Indirect control by the transit 
agency is possible via requests to the traffic operations center, as discussed above. 
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Exhibit 5-17: Operational Concept: Transit Management — Grade Crossings 





Operational Concept: | Grade Crossings 








Functional Area: Transit Management 





This operational concept applies to the interfaces between rail operations control centers and traffic 
management control centers, specifically for coordination of activity at at-grade rail crossings. 





Interfacing Agencies: | = Amtrak and Local Cities/Towns 
« Rail Operators and Local Cities/Towns 
«Rail Operators and MassHighway 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Not applicable. 





Event Information: | Information Sharing: Event information, such as construction activity affecting a grade 
crossing or rail schedule information, will be exchanged between the two control 
centers through a shared connection to a centralized database. Each agency will 
enter event information into the database. Entering of information may be manual, by 
means of a web-based interface, or automatic, by means of an automated process 
developed for the software at each control center. Similarly, event information will be 
received by each control center either through an automated link with the central 
software or through operator monitoring of a web-based interface. 





Device Status: | Not applicable. 





Request: | Not applicable. 





Control: | Not applicable. 
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Exhibit 5-18: Operational Concept: Transit Management — Private Traveler Information 





Operational Concept: | Private Traveler Information 








Functional Area: Transit Management 





This operational concept applies to the interfaces between transit agency control centers and control centers of 
Private Traveler Information Service Providers (ISPs). 





Private Traveler ISPs and Amtrak 

Private Traveler ISPs and Local Cities and Towns (transit) 

Private Traveler ISPs and Local Human Service Transit Providers 
Private Traveler ISPs and Massport (transit) 

Private Traveler ISPs and MBTA 

Private Traveler ISPs and Private Ground Transportation Providers 
Private Traveler ISPs and BAT 

Private Traveler ISPs and CATA 

Private Traveler ISPs and GATRA 

Private Traveler ISPs and LRTA 

Private Traveler ISPs and MVRTA 

Private Traveler ISPs and TMAs 


Interfacing Agencies: 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Not applicable. 





Event Information: | Information Sharing: Service updates from the transit operations center will be 
provided to the private service provider through a shared connection to a centralized 
database. The transit operations center will enter event information into the database. 
Entering of information may be manual, by means of a web-based interface, or 
automatic, by means of an automated process developed for the software at the 
control center. The private service provider will receive event information through 
operator monitoring of a web-based interface. 


Information Sharing: Exchange of response status information, including incident 
response measures such as service modifications, will occur through a shared 
connection to a centralized database or by via voice communications in urgent 
situations. 





Device Status: | Not applicable. 





Request: | Not applicable. 











Control: | Not applicable. 
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5.2.3 EMERGENCY MANAGEMENT 


Exhibit 5-19 illustrates the interagency interfaces required to support regional emergency 
management functions. These interfaces include center-to-center interfaces among the emergency 
management centers, as well as interfaces between emergency management centers and traffic 
control centers. 


Exhibit 5-19: Interagency Interfaces — Emergency Management 
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Each of these interfaces is addressed by one of the following operational concepts: 


= Center-to-Center 


= Traffic Coordination 
a Local 
o MEMA 
2 MEMA/MassHighway 
2 State Police 


=» Transit Coordination 


These operational concepts are presented in Exhibit 5-20 through Exhibit 5-25, respectively. 
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Exhibit 5-20: Operational Concept: Emergency Management — Center-to-Center 





Operational Concept: 


Center-to-Center 





Functional Area: 








Emergency Management 


This operational concept applies to the interfaces among the various emergency management control centers. 





Interfacing Agencies: 


BEMA and Local Cities/Towns 
BEMA and MBTA 

BEMA and MEMA 

BEMA and State Police 

Local Cities/Towns and MBTA 
Local Cities/Towns and MEMA 
Local Cities/Towns and State Police 
MBTA (police) and MEMA 

MBTA (police) and State Police 
MEMA and State Police 








Information Flow 


Relationship 





Data: 


Not applicable. 





Video: 


No video exchange will be made between the two agencies. 





Event Information: 


Cooperation: Emergency event information, such as reports of accidents and other major 
incidents, will be exchanged by voice communication (phone or radio). The critical nature 
of such communication requires this direct person-to-person interface. 


Information Sharing: Non-emergency event information will be exchanged through a 
shared connection to a centralized database. Entering and viewing of information may be 
manual, by means of a web-based interface, or automatic, by means of an automated 
process developed for the control center software. 





Device Status: 


Consultation: Exchange of device status information, including incident response 
measures, will occur via voice communications. Automated exchange of device status 
information, such as the ability for one agency to monitor information being disseminated 
by another, is recommended for future implementation. 














Request: | Cooperation: All requests, such as emergency operations procedures or dissemination of 
information via the other agency’s equipment, will be made via voice communications. 
Control: | Not applicable. 
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Exhibit 5-21: Operational Concept: Emergency Management — Traffic Coordination (Local) 





Operational Concept: 


Traffic Coordination (Local) 





Functional Area: 








Emergency Management 


This operational concept applies to the interfaces between local or regional emergency management control 
centers and traffic management centers. 





Interfacing Agencies: 


Information Flow 





» BEMA and BTD = Local City/Town/County Public Safety 
» BEMA and Local Cities/Towns and Local Cities/Towns (traffic) 
«= BEMA and MassHighway * Local City/Town/County Public Safety 
= BEMA and MassPike and City of Brockton 
= BEMA and Massport = Local City/Town/County Public Safety 
= BEMA and MDC and MassHighway 
» MBTA and BTD = Local City/Town/County Public Safety 
= MBTA and Local Cities/Towns and MassPike 
= Local City/Town/County Public Safety 
and Massport 
= Local City/Town/County Public Safety 
and MDC 
Relationship 





Data: 


Not applicable. 





Video: 





Event Information: 


Information Sharing: The emergency operations center will have access to video feeds 
from select traffic cameras to support incident management operations. Pan/tilt/zoom 
control of the camera will remain in the control of the traffic management center, but 
requests for camera repositioning by the emergency operations center may be made 
via voice communications (e.g. phone or radio). 


Cooperation: Emergency event information, such as reports of accidents and other 
major incidents, will be exchanged by voice communication (phone or radio). The 
critical nature of such communication requires this direct person-to-person interface. 


Information Sharing: Non-emergency event information from the traffic management 
center, such as traffic and construction information, will be provided to the emergency 
operations center through a shared connection to a centralized database. Entering of 
information may be manual, by means of a web-based interface, or automatic, by 
means of an automated process developed for the traffic management center 
software. The emergency operations center will receive event information through 
operator monitoring of a web-based interface. 





Device Status: 


Consultation: Exchange of device status information, including incident response 
measures such as road closures and detours, will occur via voice communications. 
Coordination via phone or radio will be essential when incident response by the 
emergency operations center affects operations by the traffic management center, and 
vice versa. Automated exchange of device status information, such as the ability for 
the emergency operations center to monitor event responses by the traffic 
management center, is recommended for future implementation. 





Request: 


Control: 





Cooperation: Emergency operations center requests for CCTV camera repositioning, 
as mentioned above, will be made via voice communications. All other requests, such 
as placement of messages on VMSs controlled by the traffic management center, will 
also be made via voice communications. 








Independent: Direct control of traffic field equipment will not be permitted, as all control 
will remain with the traffic management center. Indirect control by the emergency 
operations center is possible via requests to the traffic management center, as 
discussed above. 
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Exhibit 5-22: Operational Concept: Emergency Management - Traffic Coordination (MEMA) 





Operational Concept: | Traffic Coordination (MEMA) 








Functional Area: Emergency Management 





This operational concept applies to the interfaces between the MEMA control center and traffic management 
control centers. 





MEMA and BTD 

MEMA and City of Brockton 
MEMA and Local Cities/Towns 
MEMA and MassPike 

MEMA and Massport 

MEMA and MDC 


Interfacing Agencies: 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Information Sharing: MEMA will have access to video feeds from select traffic cameras 
to support incident management operations. Pan/tilt/zoom control of the camera will 
remain in the control of the traffic operations center, but requests for camera 
repositioning by MEMA may be made via voice communications (e.g. phone or radio). 





Event Information: | Cooperation: Emergency event information, such as reports of accidents and other 
major incidents, will be exchanged by voice communication (phone or radio). The 
critical nature of such communication requires this direct person-to-person interface. 


Information Sharing: Non-emergency event information from the traffic operations 
center, such as traffic and construction information, will be provided to MEMA through 
a shared connection to a centralized database. Entering of information may be 
manual, by means of a web-based interface, or automatic, by means of an automated 
process developed for the traffic operations center software. MEMA will receive event 
information through operator monitoring of a web-based interface. 





Device Status: | Consultation: Exchange of device status information, including incident response 
measures such as road closures and detours, will occur via voice communications. 
Coordination via phone or radio will be essential when incident response by MEMA 
affects operations by the traffic operations center, and vice versa. Automated 
exchange of device status information, such as the ability for MEMA to monitor 
messages displayed on VMSs controlled by the traffic operations center, is 
recommended for future implementation. 





Request: | Cooperation: MEMA requests for CCTV camera repositioning, as mentioned above, 
will be made via voice communications. All other requests, such as placement of 
messages on VMSs, will also be made via voice communications. 





Control: | Independent: Direct control of traffic field equipment will not be permitted, as all control 
will remain with the traffic operations center. Indirect control by MEMA is possible via 
requests to the traffic operations center, as discussed above. 
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Exhibit 5-23: Operational Concept: Emergency Management — Traffic Coordination (MEMA and 
MassHighway) 





Operational Concept: | Traffic Coordination (MEMA and MassHighway) 








Functional Area: Emergency Management 





This operational concept applies to the interface between MEMA and MassHighway. This interface differs from 
the other “Traffic Coordination” interfaces in that direct control of MassHighway’s central software and field 
equipment by MEMA will be possible under certain circumstances. The interface will be implemented between 
the MEMA Operations Center and the MassHighway Traffic Operations Center. 





Interfacing Agencies: | = MEMA and MassHighway 








Information Flow | Relationship 





Data: | Not applicable. 





Video: | Information Sharing: MEMA will have access to video feeds from select MassHighway 
cameras to support incident management operations. In non-critical conditions, 
pan/tilt/zoom control of the camera will remain in the control of MassHighway, but 
requests for camera repositioning by MEMA may be made via voice communications 
(e.g. phone or radio). 


Control Sharing: A back-up operator workstation for the MassHighway TOC will be 
located at the MEMA Operations Center. This workstation will have the same 
functionality as workstations in the TOC, allowing full control of all MassHighway field 
equipment. In critical circumstances, MEMA will be able to view and control 
MassHighway cameras via the remote TOC workstation. 





Event Information: | Cooperation: Emergency event information, such as reports of accidents and other 
major incidents, will be exchanged by voice communication (phone or radio). The 
critical nature of such communication requires this direct person-to-person interface. 


Information Sharing: Non-emergency event information from MassHighway, such as 
traffic and construction information, will be provided to MEMA through a shared 
connection to a centralized database. The MassHighway central software will 
automatically send event information to the database. MEMA will receive event 
information through operator monitoring of a web-based interface. 





Device Status: | Information Sharing: Automated exchange of MassHighway device status information 
will be provided through the remote TOC workstation. This will provide MEMA with the 
ability to monitor response measures, such as messages displayed on MassHighway 
VMSs. 





Request: | Cooperation: MEMA requests for CCTV camera repositioning, as mentioned above, 
will be made via voice communications. All other requests, such as placement of 
messages on MassHighway VM§Ss, will also be made via voice communications. 





Control: | Control Sharing: As mentioned above, MEMA will be able to take direct control of 
MassHighway field equipment under critical circumstances. The back-up TOC 
workstation will have the same functionality as workstations in the TOC, allowing full 
control of all MassHighway field equipment. 
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Exhibit 5-24: Operational Concept: Emergency Management — Traffic Coordination (State Police) 





Operational Concept: 


Traffic Coordination (State Police) 





Functional Area: 








control centers. 


Emergency Management 


This operational concept applies to the interfaces between the State Police and the various traffic management 





Interfacing Agencies: 


State Police and BTD 

State Police and City of Brockton 
State Police and Local Cities/Towns 
State Police and MassHighway 
State Police and MassPike 

State Police and Massport 

State Police and MDC 








Information Flow 


Relationship 





Data: 


Not applicable. 





Video: 


Information Sharing: The State Police will have access to video feeds from select traffic 
cameras to support dispatching and event management operations. Pan/tilt/zoom 
control of the camera will remain in the control of the traffic operations center, but 
requests for camera repositioning by the State Police may be made via voice 
communications (e.g. phone or radio). 





Event Information: 


Cooperation: Emergency event information, such as reports of accidents and other 
major incidents, will be exchanged by voice communication (phone or radio). The 
critical nature of such communication requires this direct person-to-person interface. 


Information Sharing: Non-emergency event information from the traffic operations 
center, such as traffic and construction information, will be provided to the State Police 
through a shared connection to a centralized database. Entering of information may 
be manual, by means of a web-based interface, or automatic, by means of an 
automated process developed for the traffic operations center software. The State 
Police will receive event information through operator monitoring of a web-based 
interface. 





Device Status: 


Consultation: Exchange of device status information, including incident response 
measures such as road closures and detours, will occur via voice communications. 
Coordination via phone or radio will be essential when incident response by the State 
Police affects operations by the traffic operations center, and vice versa. Automated 
exchange of device status information, such as the ability for the State Police to 
monitor messages displayed on VMSs controlled by the traffic operations center, is 
recommended for future implementation. 
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Request: | Cooperation: State Police requests for CCTV camera repositioning, as mentioned 
above, will be made via voice communications. All other requests, including the use of 
VMSs for displaying emergency messages (such as Amber Alert messages), will also 
be made via voice communications. 
Control: | Independent: Direct control by the State Police of roadway field equipment will not be 


permitted, as all control will remain with the traffic operations center. Indirect control by 
the State Police is possible via requests to the traffic operations center, as discussed 
above. 
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Exhibit 5-25: Operational Concept: Emergency Management — Transit Coordination 





Operational Concept: 


Transit Coordination 





Functional Area: 








Emergency Management 


This operational concept applies to the interfaces between local or regional emergency management control 
centers and transit management centers. 





Interfacing Agencies: 


Local City/Town/County Public Safety and BAT 

Local City/Town/County Public Safety and CATA 

Local City/Town/County Public Safety and GATRA 

Local City/Town/County Public Safety and LRTA 

Local City/Town/County Public Safety and MBTA 

Local City/Town/County Public Safety and MVRTA 

Local City/Town/County Public Safety and Local City/Town Shuttle Services 








Information Flow 


Relationship 





Data: 





Video: 


Not applicable. 
Not applicable. 





Event Information: 


Cooperation: Emergency event information, such as reports of major incidents or 
incident response measures such as service modifications, will be exchanged by voice 
communication (e.g. phone or radio). The critical nature of such communication 
requires this direct person-to-person interface. 


Information Sharing: Non-emergency event information from the transit management 
center, such as service updates, will be provided to the emergency operations center 
through a shared connection to a centralized database. Entering of information may 
be manual, by means of a web-based interface, or automatic, by means of an 
automated process developed for the central software at the transit management 
center. The emergency operations center will receive event information through 
operator monitoring of a web-based interface. 





Device Status: 


Not applicable. 














Request: | Coordination: Requests, such as those for service modifications such as vehicle 
holding or rerouting, will be made via voice communications. An automated system 
and protocol is recommended for situations where requests are frequent. 

Control: | Not applicable. 
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5.2.4 DATA ARCHIVES 


Exhibit 5-26 illustrates the interagency interfaces required to support regional data archive 
management functions. These include interfaces with the Office of Transportation Planning 
(proposed as the hub of an integrated data archive system), as well as an interface between the 
RMV and state/local police for crash reporting. 


Exhibit 5-26: Interagency Interfaces — Data Archives 
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Each of these interfaces is addressed by one of the following operational concepts: 


» Planning Archives 
"Crash Data System 


These operational concepts are presented in Exhibit 5-27 and Exhibit 5-28, respectively. 
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Exhibit 5-27: Operational Concept: Data Archives — Planning Archives 





Operational Concept: | Planning Archives 








Functional Area: Data Archives 





This operational concept addresses the interfaces between the Office of Transportation Planning (OTP) and 
other agencies holding data archives. As envisioned by the architecture, OTP will serve as the regional 
archived data management system hub, holding information managed by OTP as well as providing a portal to 
the information held by other agencies. 





OTP and BTD 
OTP and CTPS 
OTP and MassHighway 
OTP and MassPike 
OTP and Massport 
OTP and MBTA 
OTP and RMV 
OTP and MAPC 
OTP and MVPC 
OTP and NUCOG 
OTP and OCPC 
OTP and SRPEDD 


Interfacing Agencies: 








Information Flow | Relationship 





Data: | Information Sharing: As the regional archived data management system hub, the 
Office of Transportation Planning archive will hold key data collected and reported by 
other agencies. However, data exchange will also be possible between OTP and each 
of the other agencies’ archives, allowing OTP to serve as a portal to other data held by 
other agencies. This will provide OTP with access to data held by the other agencies, 
and will provide the other agencies with access to data held by OTP. Moreover, this 
will also provide participating agencies with access to each others’ data, allowing one 
RPA, for example, to access data held by an adjacent RPA through the system 
maintained by OTP. 


This data exchange will occur over a link between the databases at each location. 
Access to data on the other systems will be initiated by the agency requesting the 
information. 





Video: | Not applicable. 





Event Information: | Not applicable. 





Device Status: | Not applicable. 





Request: | Information Sharing: As noted above, data exchange will occur between the databases 
following a request by the initiating agency. 











Control: | Not applicable. 
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Exhibit 5-28: Operational Concept: Data Archives — Crash Data System 





Operational Concept: | Crash Data System 








Functional Area: Data Archives 





This operational concept applies to the interface between the RMV and state/local police, which supports the 
exchange of information between police systems and the RMV Crash Data System. 





Interfacing Agencies: | = RMV and State Police 
" RMV and Local Public Safety 








Information Flow | Relationship 





Data: | Information Sharing: Data exchange will occur over a link between the police and the 
RMV database. This interface will allow submission of records to the RMV database 
by state or local police. 





Video: | Not applicable. 





Event Information: | Not applicable. 





Device Status: | Not applicable. 





Request: | Information Sharing: Data exchange will occur between the databases following a 
request by the initiating agency. 











Control: | Not applicable. 
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5.2.5 ELECTRONIC FARE PAYMENT 


Exhibit 5-29 illustrates the interagency interfaces required to support regional implementation of 
electronic fare payment. The plan for EFP in the region is based on a Regional Fare Card that will 
be interoperable among the various transit agencies. It is envisioned that this regional fare card will 
be interoperable with the fare card that is currently being introduced by the MBTA. However, for the 
purposes of the architecture, the regional fare card will be considered as a separate entity managed 
by a generic “Regional Fare Card agency.” 


Exhibit 5-29: Interagency Interfaces — Electronic Fare Payment 





The interfaces to support electronic fare payment are addressed by a single operational concept, as 
presented in Exhibit 5-30. 
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Exhibit 5-30: Operational Concept: Electronic Fare Payment 





Operational Concept: | Electronic Fare Payment 








Functional Area: Electronic Fare Payment 





This operational concept applies to the interagency interfaces required to support regional implementation of 
electronic fare payment. 





Interfacing Agencies: Regional Fare Card Agency and Local City/Town Shuttle Services 
Regional Fare Card Agency and MBTA 

Regional Fare Card Agency and Private Ground Transportation Providers 
Regional Fare Card Agency and BAT 

Regional Fare Card Agency and CATA 

Regional Fare Card Agency and GATRA 

Regional Fare Card Agency and LRTA 

Regional Fare Card Agency and MVRTA 

Regional Fare Card Agency and TMAs 








Information Flow | Relationship 





Data: | Information Sharing: The Regional Fare Card Agency will hold all administrative and 
financial data related to the fare cards. In order for the fare card to be used on 
services by the transit providers in the region, data exchange is required between the 
fare collection systems of the transit providers and the Regional Fare Card Agency. 
Two primary data exchanges are required. 


The first data exchange occurs when the fare card is used on a transit provider's fare- 
box. At that time, the fare card information is sent to the Regional Fare Card Agency 
for validation, ensuring that the balance on the card is adequate and deducting the fare 
from the balance. 


The second data exchange occurs when the transit provider’s account is reconciled 
with the Regional Fare Card Agency. This is usually done periodically, e.g. at the end 
of each service day. At that time, the total value of the transit provider’s fares paid by 
fare cards is transferred from the Regional Fare Card Agency to the transit provider. 





Video: | Not applicable. 





Event Information: | Not applicable. 





Device Status: | Not applicable. 





Request: | Information Sharing: The data exchange occurring during the validation of the fare card 
will be performed following a request of the transit provider. This request will be 
initiated upon the use of the fare card in the transit provider's farebox. 





Control: | Not applicable. 
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5.2.6 ELECTRONIC TOLL COLLECTION 


Exhibit 5-31 illustrates the interagency interfaces required to support regional implementation of 
Electronic Toll Collection (ETC). As the MassPike is the ETC system provider for the region, these 
consist of the interfaces between the Massachusetts Turnpike Authority’s Account Processing 
Center (APC) and other agencies accepting the toll transponders. These agencies include other toll 
agencies outside of the region (e.g. E-ZPass Inter-Agency Group members) as well as parking 
facility operators. 


Exhibit 5-31: Interagency Interfaces — Electronic Toll Collection 
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These interfaces are addressed by a single operational concept, as presented in Exhibit 5-32. 
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Exhibit 5-32: Operational Concept: Electronic Toll Collection 





Operational Concept: | Electronic Toll Collection 








Functional Area: Electronic Toll Collection 





As the MassPike is the ETC system provider for the region, this operational concept applies to the interfaces 
between the Massachusetts Turnpike Authority’s Account Processing Center (APC) and other agencies 
accepting the toll transponders, including parking facility operators. 





Interfacing Agencies: MassPike and Massport (Tobin) 
MassPike and Other Toll Agencies 
MassPike and BTD 

MassPike and Local Cities/Towns 
MassPike and MBTA 

MassPike and Massport (Logan) 
MassPike and BAT 

« MassPike and CATA 

» MassPike and GATRA 

« MassPike and LRTA 


» MassPike and MVRTA 








Information Flow | Relationship 





Data: | Information Sharing: As the lead agency in the implementation of ETC, the MassPike 
will hold all administrative and financial data related to the toll transponders. In order 
for the toll transponders to be used at non-Turnpike facilities in the region, data 
exchange is required between the toll collection system of the other operator and the 
MassPike. Two primary data exchanges are required. 


The first data exchange occurs when the transponder is used at the other operator’s 
toll facility. At that time, the other operator’s toll system sends the transaction 
information to the MassPike, which deducts the appropriate amount from the 
customer's account. 


The second data exchange occurs when the other toll operator’s account is reconciled 
with the MassPike. At that time, the total value of the ETC transactions at the other toll 
facility is transferred from the MassPike to the other operator. 





Video: | Not applicable. 





Event Information: | Not applicable. 





Device Status: | Not applicable. 





Request: | Information Sharing: The data exchange occurring during the toll transaction will be 
performed following a request of the other operator’s toll system. This request will be 
initiated upon the reading of a MassPike toll transponder by the other agency’s toll 
system. 





Control: | Not applicable. 
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5.3 Institutional Coordination 


The Regional ITS Architecture provides both a technical and institutional framework for the 
deployment of ITS in the Metropolitan Boston region. This involves coordination between various 
agencies and jurisdictions to achieve seamless operations and/or interoperability. The existing and 
recommended operational concepts defined in the previous section provide guidance for the 
functional requirements of inter-jurisdictional interactions. These inter-jurisdictional operational 
concepts in turn point directly to the types of agreements that may be required between individual 
agencies in order to define the agency roles and responsibilities for each of these interactions. This 
section discusses considerations for developing inter-jurisdictional agreements for implementing the 
operational concepts, achieving the information flows, and operating the systems defined in the 
regional architecture. 


5.3.1 EXISTING AGREEMENTS 


Interagency coordination already occurs among the operating agencies in the Metropolitan Boston 
region. In some cases, the responsibilities of the coordinating agencies are detailed in interagency 
agreements or Memoranda of Understanding (MOUs), which provide formal documentation of 
agency roles, procedures, and responsibilities. In many cases, however, such as where 
jurisdictions meet or overlap, coordination occurs without formal agreements. In these cases, 
protocols may have been developed at the operating level, and the cooperating agencies rely on 
informal arrangements. 


This section documents information regarding formal and informal interagency agreements relevant 
to the Regional ITS Architecture. This information was obtained from the initial architecture input 
meetings and subsequent contact with stakeholders. Exhibit 5-33 summarizes the operational 
agreements identified by the stakeholders in the region. Each of the agreements is discussed in 
the following subsections. 
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Function 


Traffic 
Management 


Incident 
Management 


Multimodal 
Coordination 


Traveler 
Information 


Electronic 
Toll 
Collection 


Emergency 
Management 


REGIONAL ITS ARCHITECTURE FOR METROPOLITAN BOSTON 


Exhibit 5-33: Existing Operational Agreements 


Participants 


MassHighway, 
MassPike 


Agreement 


Control center co-location 


Status 


Formalized (April 2000) 





BTD, MassPike 


CA/T video sharing 


Not formalized 





BTD, MassHighway, 
MBTA 


Video and information sharing 


Formalized (2004) 





BTD, MDC 


MDC traffic signal operation 
(Boston) 


Not formalized 





BTD, Massport 


MassHighway, 
MassPike, State 
Police, et al. 


Massport traffic signal 
operation (S. Boston) 


Unified Response Manual for 
Roadway Traffic Incidents 


Under discussion 


Formalized (December 
1998), Update under 
development 





MassHighway, State 
Police 


Accident Response/Quick 
Clearance Agreement 


Formalized (August 2003) 





MassHighway, 
MassPike, Massport, 
et al. 


CA/T Incident Management & 
Communication Agreement 


Formalized (December 
1995), Updated 2001 





MassHighway, 
Massport 


BTD, MBTA 


MassHighway, 
SmarTraveler 


Mutual aid (Tobin Bridge 
incidents) 


Transit signal priority 


Traveler information services 


Not formalized 


Not formalized 


Formalized (MassHighway 
contract) 





MBTA, SmarTraveler 


Traveler information services 


Formalized (MBTA contract) 





Massport, 
SmarTraveler 


MassPike, Massport, 
IAG 


Travel time data from Logan 
Express vehicles 


E-ZPass toll coalition 


Not formalized 


Formalized (coalition 
members) 





MassPike, Massport 


Tobin Bridge electronic toll 
collection 


Formalized 





MassPike, MBTA 


BEMA et al. 


ETC parking facility payment 


Boston emergency 
management plans 


Formalized 


Formalized 





MEMA, State Police, 
et al. 


Massachusetts Amber Alert 
Plan 


Formalized (October 2002) 





MassHighway, State 
Police 


Expansion of Amber Alert Plan 
(highway VMSs) 


Under development 
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53.1.1 Traffic Management 


Agreements regarding traffic management fall into two primary categories: control center 
coordination and traffic signal control. Agreements regarding control center coordination are the 
following: 


=» An agreement between MassHighway and the Massachusetts Turnpike for co- 
location of MassHighway’s Regional Traffic Operations Center (RTOC) at the CA/T 
Operations Control Center in South Boston. A formal agreement was signed in April 
2000. 


= Access to Central Artery/Tunnel (CA/T) project CCTV images at the BTD Traffic 
Management Center. Camera control remains with the CA/T. No formal agreement 
has been established. 


» BTD, MassHighway, and the MBTA have signed an agreement to share information 
among the BTD Traffic Management Center, the MBTA’s Operations Control Center, 
and MassHighway’s RTOC. This agreement includes video sharing, established 
through the Massachusetts Interagency Video Information System (MIVIS), as well as 
data sharing and communications network expansion. 


For traffic signal operations, no formal agreements are in place. However, existing coordination is 
described below: 


= Out of approximately 124 signalized intersections on MDC roadways within the city of 
Boston, 20 are linked with BTD’s central system and are operated from its TMC. No 
formal agreement has been established. 


= BTD is in discussion with Massport regarding the potential operations of Massport 
traffic signals in South Boston by BTD. This same issue will need to be addressed for 
the traffic signals along the CA/T corridor. 


5.3.1.2 Incident Management 


The following formal agreements have been established for incident management: 


«The Unified Response Manual (URM) for Roadway Traffic Incidents establishes a statewide 
traffic management plan for roadway incidents. The scope of the manual is limited to 
incidents on designated National Highway System (NHS) roadways and other principal 
arterials. The URM was developed by the Massachusetts Operations Action Group, 
consisting of representatives from the following agencies: 


o Massachusetts Highway Department 

« Massachusetts Turnpike Authority 

2 Massachusetts Department of Public Health 

ao Federal Highway Administration 

ao Massachusetts State Police 

2 Fire Chiefs’ Association of Massachusetts 

2 Massachusetts Department of Environmental Protection 
2 Statewide Towing Association 


The original agreement was approved and signed in December 1998, but is currently being 
updated. 


«An “Accident Response / Quick Clearance Agreement” between MassHighway and the 


State Police, originally signed in April 1993, is included in the 1998 URM as an annex. This 
agreement has since been updated, a revised version having been signed in August 2003. 
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"As part of the CA/T project, an Incident Management and Communication Agreement 
was developed by and among the following agencies: 


o Massachusetts Highway Department 
o Massachusetts Turnpike Authority 

co Massachusetts Port Authority 

a Massachusetts State Police 

2 Boston Fire Department 

2 Boston Emergency Medical Services 
2 Boston Police Department 

2 Boston Transportation Department 


An initial agreement was developed and approved for the opening of the Ted Williams 
Tunnel in December 1995. The document was revised in 2001 in anticipation of 
opening additional portions of the project, but this revised draft has not been formally 
approved. 


Informal mutual-aid agreements also exist between agencies for incident response. For example, 
Massport and MassHighway coordinate response to incidents on the Tobin Bridge and its 
approaches without formal written agreements. 


5.3.1.3 Multimodal Coordination 


Agreements for multimodal coordination in the region relate to traffic signal priority for MBTA transit 
vehicles. BTD is working with the MBTA on transit signal priority on Washington Street as part of 
the Silver Line project. Signal priority is also provided to Green Line vehicles on Commonwealth 
Avenue. However, no formal agreements have been established for this coordination. 


5.3.1.4 Traveler Information 


SmarTraveler, a private traveler information service provider, is under contract with MassHighway 
and the MBTA to provide traveler information services to those agencies. SmarTraveler also has 
an agreement with Massport to obtain travel time information from Logan Express buses acting as 
probe vehicles. This agreement is not formalized, however. SmarTraveler also has access to MDC 
radio frequencies as a source of incident information. 


5.3.15 Electronic Toll Collection 


The Massachusetts Turnpike Authority operates the “Fast Lane” electronic toll collection (ETC) 
system for use at its toll plazas across the state. The Turnpike Authority is a member of the Inter- 
Agency Group (IAG), a coalition of toll agencies in the Northeast U.S. operating the E-ZPass ETC 
system, with which the Fast Lane system is interoperable. 


Massport, which operates the Tobin Bridge toll plaza, is also a member of the IAG. However, 
Massport does not issue toll transponders and instead relies on the Turnpike Authority to issue 
transponders and administer accounts. The Turnpike Authority's Account Processing Center (APC) 
handles these functions and manages the transfer of Tobin Bridge toll charges to Massport. An 
MOU between Massport and the Turnpike Authority formalizes this relationship. 


Fast Lane transponders are also accepted for payment at the Route 128 MBTA/Amirak parking 


garage in Westwood. Massport is also planning support for Fast Lane payment in its new parking 
management and revenue control system for its garages at Logan Airport. 
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5.3.1.6 Emergency Management 


The Boston Emergency Management Agency (BEMA), in association with other emergency 
management agencies in the region, has developed of a number of emergency management plans 
that establish procedures for coordination during emergencies. These include the following: 


Boston Emergency Response Plan 

Boston Comprehensive Emergency Management Plan 

Boston’s Emergency Liaisons Response Plan 

Boston’s Interoperability Communications Plan 

Boston’s Critical Incident Exodus Evacuation Plan 

Boston’s Emergency Shelters 

Boston’s Local Emergency Planning Committee Title III Facilities 

Boston’s Corporate Community Access Plan for Business Continuity 
Boston’s Threat Conditions Matrix Response Plan 

Boston’s Threat and Vulnerability Analysis 

Critical Public Safety Infrastructure Earthquake Analysis and HAZUS (Loss 
Estimation Software) 

« Boston’s Consequences Assessment Tool Set (CATS) and Hazard Prediction and 
Assessment Capability (HPAC) (Plume Modeling Capability) 


5.3.1.7 Amber Alerts 


The Massachusetts Amber Alert Plan documents the criteria and procedures for issuing public 
alerts about abducted children and their kidnappers. The initial implementation of the plan in 
October 2002 was an agreement by and among the Massachusetts Chiefs of Police Association, 
the Massachusetts State Police, the Massachusetts Emergency Management Agency (MEMA), and 
local broadcasters for the broadcast of child abduction alert messages via radio, cable and 
television stations statewide. 


Extension of the plan to include posting of messages on highway variable message signs is under 
development. MassHighway is leading a project to review and establish policies and procedures for 
managing Amber Alert notifications. Participants in this project include MassHighway, MassPike, 
Massport, SmartRoutes, MEMA, and the State Police. 


5.3.2 ELEMENTS OF AN AGREEMENT 


Agreements are established to clearly define responsibilities among the involved parties. The level 
of formality generally increases as risks escalate and when financial transactions take place. 
Formality will also increase when the performance or lack of performance on the part of one agency 
impacts the operations of another. For example, if an agency maintains and operates the traffic 
signals of another agency, clear definition of responsibilities for both parties will help ensure smooth 
operations. 


Exhibit 5-34 presents a list of elements to consider in the development of an agreement for ITS 


operations and maintenance. Not all elements are relevant to each exchange of information. The 
level of specificity will depend on the nature of the interface. 
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Exhibit 5-34: Elements of an Agreement 














Operational Concept (a layperson’s 
introduction to the nature and purpose of 
the agreement) 


Benefits of the agreement (e.g. 
operational, economic) 


Duties of Responsible Agencies (a 
summary of duties and responsibilities) 


Data Sharing (aspects of sharing data to 
be considered) 


Provision of Data 
Data Rights 

Data Reuse 

Data Identification 
Data Availability 
Data Accuracy 


Oo Oo Oo Oo Oo Oo 


Control Sharing (aspects of sharing 
control to be considered with rights and 
priorities being clearly understood) 


© Provision of Control 
Control Rights 
Control Restrictions 
Control Priority 
Control Availability 


Oo Oo Oo Oo 


Connections (defines how the connection 
is made) 


Provision of Equipment 
Physical Access Point 
Demarcation Point / Boundary 
Security 

Configuration Management 
Standards and Protocols 


Oo Oo Oo Oo Oo Oo 


=» System Documentation 


= Operations 


2 Contacts 
2 Hours of Operations 
2 Responsibilities 


= Maintenance 


2 Contacts 
2 Hours of Operations 
2 Responsibilities 
«2 Response Time 
« — Liability 


a Indemnity 
2 Damage to Equipment 


=" Ownership 
2 Equipment 
2 Software 
a Intellectual Property 


= Coordination 
a Notification 


ao Periodic Reporting 

a2 Pre-Change Coordination 
= Dispute Resolution 
= Termination of Agreement 


= Compensation 
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5.3.3 RECOMMENDED AGREEMENTS 


In general, all interagency interfaces identified in this architecture should be covered by formal 
agreements. This includes interfaces under development or proposed in the architecture that have 
not yet been implemented, as well as interfaces that are currently operational but without a formal 
agreement. 


5.3.3.1 Formalization of Existing Working Arrangements 


Although some existing informal agreements may be operating without apparent problems, there 
are a number of considerations that point to the need for adoption of a formal agreement: 


«Rationale for agreement: A formal agreement that explains the reasoning behind the 
agreement and that lays out the benefits of the cooperation will help justify the 
arrangement to the participating parties, other agencies that would benefit from 
coordination, and to the public. This will help build and maintain support for 
continuing a beneficial relationship, especially when the agreement may be 
reconsidered in the future. 


=» Documentation of procedures: By documenting existing procedures that are 
operating successfully, a formal agreement can help maintain an interface in the face 
of personnel or administrative change. An informal agreement that relies solely on 
interpersonal relationships at the operating level may quickly dissolve if operating 
staff changes occur. 


« Institutional commitment: Adopting a formal agreement shows commitment by the 
participating agencies to continue the relationship. While an informal agreement 
shows commitment at the operating level, a formal agreement shows commitment at 
the institutional level. Support for a relationship at the administrative levels of the 
participating agencies will be essential for continued operation of the interface. 


« Address liability issues: In a cooperative arrangement, situations may arise where 
one or both parties may be held liable for damage or injuries sustained as a result of 
human or technical error. A formal agreement that documents agency roles and 
responsibilities with consideration for liability concerns will speed the process of 
conflict resolution and reduce resulting legal costs. 


For the reasons outlined above, it is therefore recommended that existing working arrangements be 
considered for formalization. Especially important are those working arrangements that involve 
technical coordination and cost considerations, as well as arrangements involving public safety. 
Therefore, the following existing arrangements are recommended for formalization: 


= BTD and MassPike: CA/T video sharing 

* BTD and MDC: MDC traffic signal operation 

= BTD and MBTA: Transit signal priority 

» MassHighway and Massport: Mutual aid for Tobin Bridge incidents 


5.3.3.2 Agreements for New Interfaces 


Agreements should also be developed for the new interfaces proposed in the Regional ITS 
Architecture. All of the interagency interfaces in the architecture are identified and categorized in 
Section 5.2. As with the existing informal agreements, all interfaces should have formal 
agreements. However, the key interfaces to consider initially are those involving technical 
coordination and those involving emergency management, as shown in Exhibit 5-35. 


Page 60 


FINAL REPORT REGIONAL ITS ARCHITECTURE FOR METROPOLITAN BOSTON 


Exhibit 5-35: Recommended Agreements for New Interfaces 


Functional Area Interface Type 
Roadway Management Center-to-Center 


. Center-to-Center 
Transit Management : — 
Traffic Coordination 








Center-to-Center 
Emergency Management : — 

Traffic Coordination 
Data Archives Planning Archives 
Electronic Fare Payment | Regional Fare Card 


, . Parking Facility 
Electronic Toll Collection 





5.3.3.3 Sample Interagency Agreements 


To illustrate the components of an interagency agreement, Appendix F presents two sample 
interagency agreements: 


« The first is an example of an agreement between an RTA and a municipality. This 
agreement corresponds to the “Transit Management — Traffic Coordination and Signal 
Priority” operational concept that was shown in Exhibit 5-16. 


= The second is an example of an agreement between a traffic management agency and an 
emergency management or public safety agency. This agreement corresponds to the 
“Emergency Management — Traffic Coordination” operational concept that was shown in 
Exhibit 5-21. 


As recommended, the agreements document the rationale for the agreement as well as the 
operational procedures that govern the relevant interfaces. 


March 2005 Page 61 


FINAL REPORT REGIONAL ITS ARCHITECTURE FOR METROPOLITAN BOSTON 


This page intentionally left blank. 


March 2005 Page 62 


FINAL REPORT REGIONAL ITS ARCHITECTURE FOR METROPOLITAN BOSTON 


March 2005 


6. IMPLEMENTATION PLAN 


This chapter presents a strategy for implementing the systems defined in the Regional ITS 
Architecture for Metropolitan Boston. This strategy is developed directly from preceding steps in 
the architecture development process, as illustrated in Exhibit 6-1. 
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Exhibit 6-1: Implementation Plan Development Process 


The architecture identifies a large number of ITS elements for the region, classified as either 
“existing” or “planned.” Elements classified as “existing” are those that are already implemented or 
those that are far enough along in the design stage that the interfaces are already determined. 
These elements, identified in the ITS inventory from the needs analysis, therefore are not 
addressed in the Implementation Plan. 


The elements that must be considered in the Implementation Plan are those classified as “planned,” 
i.e. those that have not yet been designed or implemented but that are envisioned to be 
implemented within a ten-year horizon. These elements were identified based on the outcome of 
the Needs Analysis and the input from stakeholders during the architecture workshop. In addition 
to the planned ITS elements, there are planned interfaces that must be considered. For example, a 
planned interface between two existing control centers must be included in the Implementation 
Plan, even though it is not associated with a planned element in the inventory. 


In developing the Implementation Plan, the planned elements identified are considered both by 
function and by stakeholder. Considered functionally, the planned elements are grouped into 
program areas that encompass elements that address a specific functional need. Each program 
area represents a general area for investment identified through the architecture development 
process. 


Within each of the program areas, a series of initiatives is defined, representing a means of 
implementing the elements with that program area. Each initiative may encompass a number of 
planned elements that are recommended for simultaneous implementation. Although a single 
stakeholder will lead some initiatives, many initiatives will require the participation of two or more 
agencies. 


As an example, consider the interface between a MassHighway District Office and MassHighway 
maintenance vehicles. The information flows between these entities include maintenance and 
construction dispatch data, location data, and status data. These interfaces can be grouped under 
a single initiative, namely “MassHighway CAD/AVL,” as each of these information flows would likely 
be implemented as part of a single CAD/AVL deployment. These interfaces would also fall under a 
broader program area, namely “CAD/AVL for Maintenance Vehicles,” that would also include 
CAD/AVL projects for maintenance vehicles at other agencies, such as local cities and towns. As 
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the example illustrates, the program area defines the functional area recommended for 
implementation, namely CAD/AVL for Maintenance and Construction, while the initiative defines a 
specific deployment. 


Finally, the Implementation Plan also considers prioritization of the identified initiatives, identifying 
candidates for near-term and longer-term implementation. This prioritization is based on the needs 
analysis, the input received from the stakeholders throughout the architecture development 
process, and interdependencies among the initiatives. 


Through this process, a comprehensive list of program areas and initiatives has been developed 
that encompasses all of the planned elements from the architecture. The remainder of this chapter 
is organized as follows: 


" Section 6.1 presents the program areas and initiatives of the Implementation Plan, grouped 
by function. 


« Section 6.2 presents the strategy for implementation, considering the prioritization of the 
initiatives identified in Section 6.1. 


6.1 Program Areas and Initiatives 


This section presents a set of program areas, along with a recommended set of initiatives to be 
implemented within each program area. Each program area represents a general area of 
investment that is needed for implementation of the architecture. 


Presented within each program area is a series of initiatives that provide a method of implementing 
that portion of the architecture. Some of the initiatives are currently planned initiatives that were 
identified in the development of the architecture. The others are recommendations for initiatives that 
address the needs identified in the development process. The initiatives defined in this section are 
not the only means by which the architecture can be implemented, however. Instead, this plan 
provides one method of grouping the planned elements of the architecture into initiatives that 
together address the needs and planned components from the architecture. 


Each of the initiatives presented indicates the stakeholders that are involved. While many initiatives 
involve only a single stakeholder, in some cases an initiative requires participation from multiple 
agencies. Furthermore, some initiatives are listed for a collective group of stakeholders, such as 
Regional Transit Authorities. These initiatives are not necessarily meant to cover multiple agencies 
or to consist of a one-time deployment. Instead, each represents an initiative that can be 
implemented multiple times within the region and on any scale, from single-agency to multi-agency 
to region-wide implementation. 


The subsections below present the program areas and initiatives arranged by function, based on 
the service areas or high-level grouping of market packages defined in the National ITS 
Architecture. The program areas are presented under the following functional groupings: 


" Traffic Management 

2 Roadway Management 

a Parking Management 
«Maintenance and Construction Management 
« Public Transportation 

2 Transit Management 

2 Electronic Fare Payment 
«Traveler Information 
= Commercial Vehicle Operations 
=» Emergency Management 
«Archived Data Management 
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In addition, there are a number of program areas that cut across multiple functions and thus do not 
fall under a single classification. These multi-function programs are presented in Section 6.1.1. 


6.1.1 MULTI-FUNCTION PROGRAM AREAS 


Presented in this section are the program areas that cut across multiple functional areas, and 
therefore cannot be classified under a single function. These program areas consist of those that 
provide or support more than one function, such as both traffic management and transit 
management. 


6.1.1.1 Information Sharing (Events) 


This program area covers the sharing of event information among the various operations centers in 
the region. This addresses the center-to-center interfaces for event data that are shown in the 
architecture between these elements, including both roadway and transit control centers. The 
functional areas covered by this program area are Traffic Management, Maintenance and 
Construction Management, Public Transportation, and Traveler Information. 


The interfaces covered by this program area can be implemented through an event reporting 
system, as recommended through the architecture development process. The following initiative 
addresses this program area. 


Event Reporting System 


This initiative will develop an event reporting system for exchanging of event information. This 
system, envisioned to be an expansion of the pilot system for Pioneer Valley developed by 
MassHighway, is an Internet-based tool that serves as a centralized repository for information on 
events affecting the transportation network. Participating agencies can enter information about 
events within their jurisdiction and can view information entered by other agencies, thus 
providing a central system for information exchange. The participating agencies are the 
following: 


=" Roadway Agencies: 
2 Boston Transportation Department (BTD) 
2 City of Brockton 
2 Local Cities/Towns 
o Massachusetts Highway Department (MassHighway) 
2 Massachusetts Turnpike Authority / Central Artery/Tunnel (MassPike / CA/T) 
2 Massachusetts Port Authority (Massport) 
2 Metropolitan District Commission (MDC) 


= Transit Agencies: 
2 Brockton Area Transit (BAT) 
2 Cape Ann Transportation Authority (CATA) 
2 Greater Attleboro-Taunton Regional Transit Authority (GATRA) 
2 Lowell Regional Transit Authority (LRTA) 
«2 Massachusetts Bay Transportation Authority (MBTA) 
a Merrimack Valley Regional Transit Authority (MVRTA) 
2 Local Cities/Towns 
2 Other Transit Providers 


=» Emergency Management Agencies: 
2 Boston Emergency Management Agency (BEMA) 
2 Local City/Town Public Safety 
so MBTA Police 
o Massachusetts Emergency Management Agency (MEMA) 
2 State Police 
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Examples of information to be exchanged include real-time information on incidents and delays, 
as well as planned events such as construction, road closures, or traffic-generating special 
events. While emergency management agencies are included in the list of participants, the 
system to be developed in this program area is only meant for the exchange of information for 
traffic and transit management purposes. Emergency management coordination is addressed 
by an extension of this system, as described in Section 6.1.9.1. 


This system will provide multiple ways for each agency to interface with the system. For 
agencies with central control center software, the system will support an automated interface 
with the agency, allowing event information to be sent directly to the system from the control 
center’s central software. For agencies that have yet to implement central operations software, 
the event reporting system can also be used as a stand-alone system, with information entered 
by an operator through a web-based interface. 


In addition to being used for information sharing among the participating agencies, the system 
will also serve as tool for information dissemination by allowing other users to view information 
entered into the system. These other users can include emergency management agencies, 
private information service providers, or even the public. The system can also serve as a 
source of data for the planned 511 Travel Information System, as described in Section 6.1.7.1. 


6.1.1.2 Information Sharing (Video) 


This program area covers the sharing of video data between the various operations centers in the 
region. This addresses the center-to-center interfaces for video data that are shown in the 
architecture between roadway control centers. The functional areas covered by this program area 
are Traffic Management, Maintenance and Construction Management, Public Transportation, and 
Traveler Information. 


The interfaces covered by this program area can be implemented through an expansion to the 
Massachusetts Interagency Video Information System (MIVIS). The following initiative addresses 
this program area. 


Expansion of MIVIS 


MassHighway, BTD, MBTA, SmartRoutes, and the State Police have already established video 
sharing in the Boston area through the Massachusetts Interagency Video Information System 
(MIVIS). This initiative expands this system to allow sharing of real-time video feeds among a 
larger group of agencies. The primary participating agencies are those with video capabilities, 
including: 


» BTD 

« Local Cities/Towns (as applicable) 

" MassHighway 

" MassPike / CA/T 

= Massport 

« Private Information Service Providers 
« State Police 


Other agencies, however, such as transit and other emergency management agencies, can also 
be included as recipients of the video data. This will Support coordination among operations 
centers within the region, allowing one center to view the CCTV images from other participating 
agencies. The system will also provide travel information functions, allowing video to be 
distributed to private information service providers or publicly available websites, such as the 
planned 511 Travel Information System website, as described in Section 6.1.7.1. The system to 
be developed through this initiative is only meant for the exchange of video for traffic and transit 
management purposes. Emergency management coordination is addressed by an extension of 
this system, as described in Section 6.1.9.1. 
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6.1.13 Interagency Communications Network 


This program area addresses the communications requirements of the center-to-center and center- 
to-field interfaces that are shown in the architecture. The functional areas covered by this program 
area are Traffic Management, Maintenance and Construction Management, Public Transportation, 
Traveler Information, and Archived Data Management. The following initiative addresses this 
program area. 


Interagency Communications Network 


This initiative establishes a communications network linking the region’s roadway and transit 
agencies. The primary participating agencies are the following: 


» BTID 

= Local Cities/Towns 
=" MassHighway 

= MassPike / CA/T 

= Massport 

» MDC 

= MBTA 


These agencies have developed or are developing communications networks to support their 
operational needs, but many of these networks do not provide the full coverage necessary for 
their operations. For example, many agencies fill the gaps in their communications networks with 
leased lines from private telecom providers, leading to high operational costs. 


This initiative takes advantage of the geographic overlap of many of these networks and 
addresses the communications requirements in two ways. First, opportunities for sharing 
existing communications infrastructure will be identified, leading to agreements for unused 
bandwidth on an agency’s network to be used by other agencies with need. This will allow better 
use of the existing network and eliminate unnecessary duplication of infrastructure. Second, 
existing gaps in the overall communications network will be identified, and these gaps will be 
filled though joint implementation projects. This will allow agencies to pool resources to build 
infrastructure that benefits each of the partners. 


The network to be developed in this program area this is meant for traffic and transit management 
purposes. Communications for emergency management is addressed in a separate initiative, as 
described in Section 6.1.9.1. 


6.1.2 TRAFFIC MANAGEMENT: ROADWAY MANAGEMENT 


6.1.2.1 Roadway Monitoring 


This program area covers improvements to the traffic monitoring capabilities of the region’s 
agencies with traffic management functions. This addresses planned elements in the architecture 
relating to field surveillance, additional deployments of field equipment and control centers, and the 
interfaces of field equipment with the appropriate control center. 


This program area addresses the need for traffic data through two means: deployment of devices 
for monitoring traffic conditions on roadways, and obtaining traffic data through probe surveillance. 
The following initiatives fall under this program area: 


Traffic Monitoring Deployment (Local Cities/Towns, including Brockton) 


This initiative covers the further deployment of devices for monitoring traffic conditions on city 
and town roads. This will include placement of vehicle detectors and roadside CCTV cameras, 
as well as devices for monitoring roadway conditions such as weather sensors. This field 
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equipment will be connected to local control centers, where it will provide data to control center 
operators. The initiative will cover the installation of these devices, establishment of control 
centers in municipalities where they are not currently present, and implementation of a 
communications link with the appropriate control center. 


Traffic Monitoring Deployment (BTD) 


This initiative covers the further deployment of devices for monitoring traffic conditions on 
roadways operated by the Boston Transportation Department. This will include installation of 
vehicle detectors and CCTV cameras. This field equipment will be monitored at the BTD Traffic 
Management Center (TMC). The initiative will cover the installation of these devices along with 
the communications link to the TMC. 


Traffic Monitoring Deployment (MassHighway) 


This initiative covers the further deployment of devices for monitoring traffic conditions on 
roadways operated by MassHighway. This will include placement of vehicle detectors and 
roadside CCTV cameras. This field equipment will be connected to the MassHighway Traffic 
Operations Center (TOC), where it will be integrated into the TOC central software. The initiative 
will cover the installation of these devices along with the communications link to the TOC. 


Traffic Monitoring Deployment (Private Information Service Providers) 


This initiative covers private-sector deployment of field equipment for traffic monitoring. This 
equipment, including vehicle detectors and roadside CCTV cameras, will be linked to centers 
operated by private travel information service providers. The initiative will cover the installation of 
this equipment, communications links with the private operations center, and communications 
links from the private operations center to relevant public-sector operations centers. 


Highway Probe Surveillance (MassHighway, MassPike) 


This initiative makes use of existing and planned vehicle identification systems to produce travel 
time data for operations and planning purposes. The prime implementing agencies will be those 
managing highway operations, namely MassHighway and the Turnpike Authority. This initiative 
will make use of probe information from systems that provide vehicle identification, including 
Electronic Toll Collection (ETC) systems and Automatic Vehicle Location (AVL) systems. Either 
through ETC roadside readers or through AVL data provided by fleet operators, the agencies will 
obtain travel time information for roadways under their jurisdiction. 


6.1.2.2 Roadway Control 


This program area covers improvements to traffic control capabilities for agencies with traffic 


management functions. This addresses planned elements in the architecture relating to information 


dissemination, as well as the interfaces of this equipment with the appropriate control center. The 


program area includes installation and expansion of centralized signal control systems as well as 


further deployment of field equipment. 


March 2005 


Expansion of City of Boston Centralized Signal Control (BTD) 


This initiative builds on the existing interface between the BTD Traffic Management Center and 
BTD Traffic Signals by expanding the scope of the centralized signal system. This initiative 
addresses a need for system expansion identified by BTD in the Needs Analysis. 


BTD operates approximately 400 signalized intersections under central control from its Traffic 


Management Center (TMC). In addition to city signals, certain signals owned by MDC, 
MassPike, and Massport are also operated from the TMC. This initiative increases the number 
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of intersections tied into the central system, thereby expanding the coverage of the control 
center and allowing greater traffic control within the city. In addition to upgrades and further 
deployment of field equipment, this initiative also covers additional communication infrastructure 
to support the expanded system. 


Centralized Signal Control (Local Cities/Towns, including Brockton) 


This initiative covers the integration of existing and new traffic signals into a centralized signal 
control system for a city or town. This would allow coordination of signals and adjustments to 
signal timings to be made in real-time from a centralized location. In addition to upgrades and 
further deployment of field equipment, this initiative also covers additional communication 
infrastructure to support the signal system. 


Expansion of Centralized Signal Control (MassHighway) 


This initiative builds on the existing interface between MassHighway Districts and MassHighway 
traffic signals by expanding the scope of existing closed-loop signal systems. This initiative 
increases the number of intersections tied into the systems at district offices, thereby expanding 
coverage and facilitating signal coordination within the region. In addition to upgrades and 
further deployment of field equipment, this initiative also covers additional communication 
infrastructure to support the expanded system. 


Variable Message Sign Deployment (BTD) 


This initiative comprises the deployment of Variable Message Signs (VMSs) on roadways 
operated by BTD. These VMSs will be controlled from the TMC, allowing real-time information to 
be disseminated to drivers on city streets. This information can include traffic conditions, routing 
information, and parking space availability. These signs will require a communications interface 
with the TMC. 


Variable Message Sign Deployment (Local Cities/Towns, including Brockton) 


This initiative comprises the deployment of Variable Message Signs on roadways operated by 
local cities and towns. These VMSs will be controlled from local control centers, allowing real- 
time information to be disseminated to drivers on city and town roads. This information can 
include traffic conditions, routing information, and parking space availability. These signs will 
require a communications interface with local control centers. 


Expansion of Variable Message Sign Deployment (MassHighway, MassPike) 


This initiative comprises the deployment of additional Variable Message Signs on roadways 
operated by MassHighway and the Turnpike Authority. Like those already deployed in the 
region, these VMSs will be controlled from the operating agency’s control center. In addition to 
upgrades and further deployment of field equipment, this initiative also covers additional 
communication infrastructure to support the system expansion. 


6.1.2.3 Roadway Management Coordination 


This program area covers improvements to coordination among agencies with traffic management 
functions. This addresses the center-to-center interfaces shown in the architecture among the 
various centers operated by traffic management agencies and private information service providers. 


In addition to the initiatives described in this section, there are a number of multi-function program 


areas that address Roadway Management Coordination, including the video integration and event 
reporting systems. These are described in Section 6.1.1. 
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Remote MassHighway TOC Workstation 


This initiative consists of the installation of a back-up workstation for the Traffic Operations 
Center (TOC) at the Massachusetts Emergency Management Agency (MEMA) in Framingham. 
This workstation will allow viewing of event and response information at MEMA under normal 
operating conditions, and will allow remote operation of MassHighway field equipment under 
emergency operating conditions. This initiative will include the workstation hardware and 
software, as well as the necessary communications between the remote workstation and the 
TOC. 


Interface between MassHighway TOC and MassPike CA/T OCC (MassHighway and MassPike) 


This initiative provides a direct data interface between the MassHighway Traffic Operations 
Center (TOC) and the MassPike CA/T Operations Control Center (OCC). The interface will 
support the exchange of traffic data such as speed, flow, and occupancy between the two 
control centers. This will allow an operator at one control center to view output from selected 
traffic detectors from the other control center. 


6.1.3 TRAFFIC MANAGEMENT: PARKING MANAGEMENT 


6.1.3.1 ETC Integration for Parking 


This program area covers acceptance of Electronic Toll Collection transponders at parking facilities 
within the region. This addresses the interfaces in the architecture between the MassPike FAST 
LANE transponders and various parking facilities and parking management systems. 


Agencies with parking facilities include BTD, Local Cities and Towns, Massport, and the MBTA. 
Due to the means by which the transponders are read, the use of the regional electronic collection 
transponders is limited to parking lots and garages with controlled entry and exit points. This 
implementation allows parking fees to be deducted from the user’s account balance. In addition to 
acceptance of the transponders at parking facilities, the system will also support reconciliation of 
accounts between each parking facility operator and the MassPike, who operates the current 
electronic toll collection program. 


ETC Integration at Parking Facilities (BTD) 


This initiative introduces acceptance of the regional ETC transponders at parking facilities 
operated by BTD. In addition to acceptance of the transponders at parking facilities, the system 
will also support reconciliation of accounts between BTD and the MassPike. 


ETC Integration at Parking Facilities (Local Cities/Towns, including Brockton) 


This initiative introduces acceptance of the regional ETC transponders at parking facilities 
operated by local cities and towns. In addition to acceptance of the transponders at parking 
facilities, the system will support reconciliation of accounts between local parking facility 
operators and the MassPike. 


ETC Integration at Parking Facilities (MBTA) 


This initiative provides for acceptance of the regional ETC transponders at MBTA-operated 
parking facilities, extending the current pilot project at the Route 128 Station parking garage. In 
addition to acceptance of the transponders at parking facilities, the system will support 
reconciliation of accounts between the MBTA and the MassPike. 
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Logan Parking Management System (Massport) 


This initiative establishes a Parking Management System for the parking facilities at Logan 
Airport. As part of this system, the regional ETC transponders will be accepted for payment at 
the parking facilities. The system also includes revenue and inventory control functions, as well 
as ITS elements such as pre-selling of parking spaces, parking space wayfinding, a pay-on-foot 
system for parking and bus ticketing, and display of parking information on airport VMSs. 


ETC Integration at Parking Facilities (Massport) 


This initiative introduces acceptance of the regional ETC transponders at Massport-operated 
parking facilities. As ETC payment at Logan parking facilities in included in the Logan Parking 
Management System project, this will cover facilities such as Logan Express parking lots. This 
system will make use of the existing agreement between Massport and the Turnpike for 
reconciliation of ETC accounts for Tobin Bridge tolls. 


ETC Integration at Parking Facilities (Other Parking Operators) 


In addition to the parking facilities operated by the agencies discussed above, there are a large 
number of parking facilities operated by other organizations. These organizations include other 
public agencies (e.g. the Massachusetts Convention Center Authority) as well as private 
companies. This initiative introduces acceptance of the regional ETC transponders at parking 
facilities parking facilities operated by these other organizations. In addition to acceptance of the 
transponders at parking facilities, the system will support reconciliation of accounts between 
parking facility operators and the MassPike. 


6.1.3.2 Regional Fare Card Integration for Parking 


This program area covers acceptance of the planned Regional Fare Card, discussed in Section 
6.1.6.2, at parking facilities operated by agencies within the region. This addresses the interfaces in 
the architecture between the Regional Fare Card and the various parking facilities and parking 
management systems. 


Agencies with parking facilities include BTD, Local Cities and Towns, Massport, the MBTA, and the 
other Regional Transit Authorities. This program area covers metered parking as well as ticketed 
parking lots and garages, allowing parking fees to be deducted from the balance on a patron’s Fare 
Card. In addition to acceptance of the new media at meters and parking facilities, the systems will 
also support reconciliation of accounts between the parking operators and the Regional Fare Card 
agency. 


Automated Fare Collection for Parking Facilities (MBTA) 


This initiative extends the MBTA’s planned Automatic Fare Collection (AFC) system, described 
in Section 6.1.6.1, to MBTA parking facilities, allowing payment by fare card for parking fees. 
This will include fare card readers at parking facility exits, potentially additional fare vending 
machines at parking facilities, and upgrading the communications infrastructure to support the 
new data requirements. 


Regional Fare Card Integration at Parking Facilities (BTD) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by BTD. This includes both on-street metered parking as well as off-street municipal 
lots. In addition to acceptance of the new media at BTD parking meters, the system will also 
support reconciliation of accounts between BTD and the Regional Fare Card agency. 
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Regional Fare Card Integration at Parking Facilities (Local Cities/Towns, including Brockton) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by local cities and towns. This will include metered parking as well as ticketed parking 
lots and garages. In addition to acceptance of the new media at meters and parking facilities, the 
system will support reconciliation of accounts between the local parking operators and the 
Regional Fare Card agency. 


Regional Fare Card Integration at Parking Facilities (Massport) 


This initiative will introduce acceptance of the planned Regional Fare Card at Massport-operated 
parking facilities. This will include Logan parking facilities (through an extension to the Logan 
Parking Management System) as well as other facilities, such as Logan Express lots. In addition 
to acceptance of the new media, the system will support reconciliation of accounts between 
Massport and the Regional Fare Card agency. 


Regional Fare Card Integration at Parking Facilities (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by Regional Transit Authorities within the study area. In addition to acceptance of the 
new media parking facilities, the system will support reconciliation of accounts between each 
RTA and the Regional Fare Card agency. 


Regional Fare Card Integration at Parking Facilities (Other Parking Operators) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by other parking facility operators. In addition to acceptance of the new media at 
parking facilities, the system will support reconciliation of accounts between the parking 
operators and the Regional Fare Card agency. 


6.1.4 MAINTENANCE AND CONSTRUCTION MANAGEMENT 


6.1.4.1 Environmental Sensors 


This program area covers the deployment of environmental sensors on roadways in the region. It 
addresses the planned environmental sensor elements in the architecture, including those for BTD, 
Massport, and local cities and towns, as well as expansion of existing deployments. 


These devices include weather stations reporting measures such as air temperature and 
precipitation, as well as sensors reporting on the condition of the roadway surface. Through a 
communications link with a central control center, the sensors will provide their information on a 
computer interface for control center operators. 


Environmental Sensors (BTD) 


This initiative comprises the deployment of environmental sensors on roadways operated by 
BTD, as well as an interface with the BTD Traffic Management Center (TMC). 


Environmental Sensors (Local Cities/Towns, including Brockton) 


This initiative comprises the deployment of environmental sensors on roadways operated by 
local cities and towns, as well as an interface with local control centers. 
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Environmental Sensors (Massport) 


This initiative comprises the deployment of environmental sensors on roadways operated by 
Massport, as well as interfaces with the relevant control centers (i.e. the Landside Operations 
Control Center, the Facilities Maintenance Unit, and/or the Aviation Operations Unit). 


6.1.4.2 CAD/AVL for Maintenance Management 


This program area covers the provision of Computer-Aided Dispatching/Automatic Vehicle Location 
(CAD/AVL) systems for managing maintenance vehicles. This addresses the planned interfaces in 
the architecture between control centers and maintenance vehicles, such as those of BTD, 
MassHighway, MassPike, and Massport. 


The systems to be implemented under this program area allow a control center to track its vehicles 
in real-time and to dispatch those vehicles in the most efficient manner. This program requires 
equipment in each vehicle to be tracked, as well as a central system at the dispatch center to 
receive and manage the tracking information. 


CAD/AVL for Maintenance Vehicles (Local Cities/Towns, including Brockton) 


This initiative provides CAD/AVL systems for managing city and town maintenance vehicles. 
This initiative will require equipment in each vehicle to be tracked, as well as a central system at 
the local dispatch center to receive and manage the tracking information. 


CAD/AVL for Maintenance Vehicles (MassHighway) 


This initiative provides a CAD/AVL system for managing MassHighway maintenance vehicles. 
Similar to the system in place for tracking the CaresVan roadway service patrol vehicles and 
snowplow contractors, this system will require equipment in each vehicle to be tracked, as well 
as central systems at the MassHighway District TOC and statewide TOC to receive and manage 
the tracking information. 


CAD/AVL for Maintenance Vehicles (MassPike) 


This initiative provides a CAD/AVL system for managing MassPike maintenance vehicles. This 
system will require equipment in each vehicle to be tracked, as well as a central system at the 
operations depots to receive and manage the tracking information. 


6.1.5 PUBLIC TRANSPORTATION: TRANSIT MANAGE MENT 


6.1.5.1 CAD/AVL for Transit 


This program area covers the provision of Computer-Aided Dispatching/Automatic Vehicle Location 
(CAD/AVL) systems for managing transit vehicles. This addresses the planned interfaces in the 
architecture between transit control centers and transit vehicles for agencies such as the MBTA and 
the other Regional Transit Authorities, Local City/Town services, and other transit providers such as 
TMAs and local human service agencies. 


The systems to be implemented under this program area allow a dispatch center to track its 
vehicles in real-time and to manage its fleet more efficiently. This will be applicable to both fixed- 
route and paratransit operations centers. For fixed-route services, real-time tracking allows more 
efficient fleet management and allows the provision of real-time service status to passengers both 
pre-trip and en-route. For paratransit services, it allows more efficient dispatching and faster 
response time. 


This information is also used to provide real-time service status to passengers both pre-trip and en- 
route. The systems will require equipment in each vehicle to be tracked, as well as a central system 
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at the dispatch center to receive and manage the tracking information. For the traveler information 
component, this system will also include a means for disseminating this information, such as 
electronic signs at shuttle stops or a websites with real-time information. 


CAD/AVL for Transit Vehicles (Local Cities/Towns) 


This initiative provides a CAD/AVL system for managing local city and town transit vehicles. This 
initiative will require equipment in each vehicle to be tracked, a central system at the local 
dispatch center to receive and manage the tracking information, and a means for disseminating 
this information to the public. 


CAD/AVL for Transit Vehicles (MBTA) 


This initiative establishes a CAD/AVL system for managing MBTA buses. Similar to the system 
in place for the Silver Line buses, this system will allow the Bus Operations Center to track 
vehicles in real-time and to manage the fleet more efficiently. This information will also be used 
to provide real-time service status to passengers both pre-trip and en-route. This initiative will 
require equipment in each vehicle to be tracked, a central system at the Operations Center to 
receive and manage the tracking information (perhaps building on the existing system for the 
Silver Line), and a means for disseminating this information to the public. 


CAD/AVL for Transit Vehicles (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative provides a CAD/AVL system for managing transit vehicles operated by Regional 
Transit Authorities within the study area, allowing an RTA dispatch center to track its vehicles in 
real-time. This initiative will require equipment in each vehicle to be tracked, a central system at 
each RTA dispatch center to receive and manage the tracking information, and a means for 
disseminating this information to the public. 


CAD/AVL for Transit Vehicles (Other Transit Providers) 


In addition to the MBTA and the other RTAs, there are a number of other providers of transit 
service in the region. These include Transportation Management Associations (TMAs), local 
human service transit providers, as well as private paratransit operators under contract with the 
MBTA. This initiative establishes a CAD/AVL system for managing transit vehicles operated by 
these other transit providers, allowing a transit dispatch center to track its vehicles in real-time. 
This initiative will require equipment in each vehicle to be tracked, a central system at each 
dispatch center to receive and manage the tracking information, and a means for disseminating 
this information to the public. 


6.1.5.2 Traffic Signal Priority 


This program area covers signal priority for buses operated by transit agencies within the study 
area. This addresses the planned interfaces between transit vehicles and traffic signal systems 
shown in the architecture. 


The systems to be implemented under this program area require coordination between the relevant 
agency and the cities or towns in which signal priority will be requested for buses. Requests for 
traffic signal priority will be made to the traffic signal system controlled by the local city/town. This 
will occur either locally at the signal controller or through a request to the central system, if the 
signal is part of such a system. Depending on the type of system used, the system may include 
elements on the buses to identify them to the signal system, elements on the controller hardware in 
the field, elements in the central signal system, and the network infrastructure to support 
communications between these system elements. 
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Traffic Signal Priority (MBTA) 


This initiative extends the signal priority system currently in place on the Silver Line to other bus 
routes in the MBTA system. This will require coordination with BTD and any other cities or towns 
in which signal priority will be requested for MBTA buses. Requests for traffic signal priority will 
be made to the traffic signal system controlled by BTD or the local city/town. 


Traffic Signal Priority (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative introduces signal priority on buses operated by Regional Transit Authorities within 
the study area. This will require coordination the relevant RTA and the cities or towns in which 
signal priority will be requested for buses. Requests for traffic signal priority will be made to the 
traffic signal system controlled by the local city/town. 


6.1.6 PUBLIC TRANSPORTATION: ELECTRONIC FARE PAYMENT 


6.1.6.1 Automated Fare Collection for the MBTA 


This program area covers the replacement of the MBTA’s existing fare collection system with a fare 
card system. This addresses the planned element of the Regional Fare Card in the architecture, as 
well as its interfaces with MBTA transit services. The system will cover fare collection on all 
subway, trolley, and bus services, with planned expansion to MBTA commuter rail services. 


Automated Fare Collection for Subway/Bus (MBTA) 


This initiative, currently being implemented, replaces the existing fare collection system with a 
cashless system based on fare cards. The Automated Fare Collection (AFC) system will consist 
of upgrades to turnstiles and fareboxes to accept the new fare media, vending machines for the 
new fare cards, a centralized fare collection and revenue management system, and supporting 
communications infrastructure upgrades. The system will cover fare collection on all subway, 
trolley, and bus services. 


Automated Fare Collection for Commuter Rail (MBTA) 


This initiative extends the AFC system to MBTA commuter rail services, allowing payment by 
fare card for commuter rail trips. This will include fare vending machines at commuter rail 
stations, fare card readers at stations or aboard trains, and upgrading the communications 
infrastructure to support the new data requirements. 


6.1.6.2 Regional Fare Card 


This program area covers acceptance of the planned Regional Fare Card (envisioned in the 
architecture to be interoperable with the MBTA’s automated fare collection system) on non-MBTA 
transit services. This program area addresses the planned interfaces between the Regional Fare 
Card and services operated by the Regional Transit Authorities and other transit providers. 


The systems to be implemented under this program area will allow fares on these services to be 
deducted from the balance carried on the Fare Card. In addition to acceptance of the new media 
aboard the vehicles, the system will also support reconciliation of accounts between the transit 
operator and the Regional Fare Card agency. 


Regional Fare Card Integration for Transit Vehicles (Local Cities/Towns) 


This initiative introduces acceptance of the planned Regional Fare Card on local shuttle services 
operated by local cities and towns. In addition to acceptance of the new media aboard the 
shuttles, the system will support reconciliation of accounts between the shuttle service operator 
and the Regional Fare Card agency. 
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Regional Fare Card Integration for Transit Vehicles (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative introduces acceptance of the planned Regional Fare Card on transit services 
operated by Regional Transit Authorities within the study area. In addition to acceptance of the 
new media aboard transit vehicles, the system will support reconciliation of accounts between 
the RTA and the Regional Fare Card agency. 


Regional Fare Card Integration for Transit Vehicles (Other Transit Providers) 


This initiative introduces acceptance of the planned Regional Fare Card on transit services 
operated by other transit providers in the region. In addition to acceptance of the new media 
aboard the buses, the system will support reconciliation of accounts between the appropriate 
transit provider and the Regional Fare Card agency. 


6.1.6.3 Regional Fare Card Integration for ETC 


This program area covers the integration of the Regional Fare Card with the regional electronic toll 
collection (ETC) transponders. This addresses the planned interface shown in the architecture 
between the Regional Fare Card and the MassPike FAST LANE transponders. The following 
initiative addresses this program area. 


Regional Fare Card Integration with ETC Transponders (Regional Fare Card Agency and MassPike) 


This initiative covers the integration of the Regional Fare Card with the regional ETC 
transponders. This initiative will extend the planned Regional Fare Card for use in highway toll 
transactions, allowing transfer of funds from the fare card to the toll transponder. In addition to 
acceptance of the fare card media by the toll transponder, the system will also support 
reconciliation of accounts between the MassPike (the operator of the FAST LANE system) and 
the Regional Fare Card agency. 


6.1.7 TRAVELER INFORMATION 


6.1.7.1 Regional Travel Information 


This program area covers the deployment of a regional travel information system, including a 
telephone-based system as well as other systems (e.g., websites, kiosks) covering the region’s 
roadways and transit services. This program covers the regional implementation of the planned 
statewide 511 Travel Information System. This addresses the planned Travel Information 
Interactive Telephone System in the architecture, as well as its interfaces with MassHighway and 
Private Information Service Provider Operations Centers. The following initiative addresses this 
program area. 


511 Travel Information System 


This initiative consists of the deployment of a public travel information system covering the 
roadways and transit services in the region. The participating agencies are the following: 


=" Roadway Agencies: 
2 BTD 
2 City of Brockton 
2 Local Cities/Towns 
o MassHighway 
2 MassPike / CA/T 
co _Massport 
2 MDC 
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= Transit Agencies: 


a ~=6BAT 

o ~=6CATA 

o GATRA 
o LRTA 

a MBTA 

a MVRTA 


© Local Cities/Towns 
o Other Transit Providers 


Although the lead agency for implementation will be MassHighway, all roadway and transit 
agencies in the region can provide information for dissemination through the system to be 
implemented under this program area. Examples of information to be provided include real-time 
information on incidents and delays, as well as planned events such as construction, road 
closures, or traffic-generating special events. 


The system will provide travel information consolidated from the various roadway and transit 
agencies in the region. A travel information website will supplement the information provided 
over the phone-based system. The proposed event reporting system, described in Section 
6.1.1.1, can serve as a source of data for this system, allowing event information to be collected 
from the various participating agencies for dissemination to the public via the telephone system 
and its associated website. 


6.1.7.2 Agency-Specific Travel Information 


This program area covers the development or expansion of travel information systems specific to 
particular roadway and transit agencies. This addresses planned components in the architecture 
relating to travel information dissemination, such as information kiosks and websites, as well as 
their interfaces with the appropriate travel information system. 


The systems to be implemented under this program area consist of central information systems that 
serve as an agency’s travel information repository, as well as the elements allowing dissemination 
of information to the public. 


Travel Information Website (BTD) 


This initiative establishes a travel information website for the City of Boston, covering the 
roadways operated by BTD. The website will provide information from the TMC such as traffic 
advisories and CCTV images. The server for this website will obtain information from the central 
systems at the TMC for dissemination to the public via the World-Wide Web. 


Travel Information Kiosks (MassPike) 


This initiative comprises the deployment of Travel Information Kiosks at service areas along the 
MassPike. The kiosks will provide travel information such as traffic conditions and weather 
advisories, as well as tourism information. These kiosks will require connections to central 
servers at the Turnpike Authority where the information will reside. 


6.1.8 COMMERCIAL VEHICLE OPERATIONS 


6.1.8.1 Automated Oversize/Overweight Credentialing 


This program area covers the provision of electronic systems for managing oversize/overweight 
vehicle permits. This addresses the elements planned in the architecture for this purpose, namely a 
central system for managing these permits electronically at Oversize/Overweight Permit Offices, as 
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well as an interface with Private Motor Carriers. The following initiative addresses this program 
area. 


Automated Oversize/Overweight Credentialing System 


This initiative establishes a computer-based system for managing oversize/overweight (OS/OW) 
vehicle permits. This includes a central system for managing these permits electronically at the 
Oversize/Overweight Permit Office at BTD, as well as an interface with Private Motor Carriers. 
This interface will allow electronic submission of credentials and permit applications, as well as 
electronic distribution of permits and credential status confirmations. 


6.1.9 EMERGENCY MANAGEMENT 


6.1.9.1 Emergency Management Coordination 


This program area covers the extension of the Interagency Communications Network and the Event 
Reporting and Video Integration Systems to support emergency management functions for the 
transportation systems in the region. This covers the planned center-to-center interfaces among 
emergency operations centers, as well as interfaces between emergency management and 
traffic/transit management centers. The following initiative addresses this program area. 


Emergency Management Network 


This initiative extends the functionality of the interagency systems proposed in the architecture, 
namely the Interagency Communications Network and the Event Reporting and Video 
Integration Systems, to support emergency management functions. The participating agencies 
are those with roadway, transit, or emergency management functions, including the following: 


=" Roadway Agencies: 
2 BTID 
2 City of Brockton 
2 Local Cities/Towns 
o MassHighway 
ec MassPike / CA/T 


«o Massport 
2 MDC 
= Transit Agencies: 

a =6BAT 
a ~=6CATA 
2 GATRA 
a LRTA 
a MBTA 
a MVRTA 


© Local Cities/Towns 
o Other Transit Providers 


» Emergency Management Agencies: 
o BEMA 
a Local City/Town Public Safety 
2 MBTA Police 
o MEMA 
ao State Police 


In emergency management, coordination among agencies may often require the transmission of 
sensitive or privileged information. This includes information that must remain restricted due to 
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security concerns and that must be managed more securely. This initiative addresses this need 
by adding a secure layer to these systems, allowing sensitive information to be accessible only 
to users with appropriate privileges. Once a user’s identification is established (e.g. through 
password or other means of verification), each user will be able to view information appropriate 
for his/her access level. 


The initiative also extends the event reporting system, described in Section 6.1.1.1, to support 
new categories and protocols for information exchange. This includes incident information 
essential for emergency response (e.g. nature of event or threat, severity, etc.) as well as 
response information (e.g. units dispatched, response plans, route diversions, etc.). The initiative 
also includes the development of tools for evacuation planning and management, allowing a 
coordinated response in case of local or regional evacuations. 


6.1.9.2 CAD/AVL for Emergency Management 


This program area provides Computer-Aided Dispatching/Automatic Vehicle Location systems for 
managing emergency vehicles. This addresses the planned interfaces in the architecture between 
emergency dispatch centers and emergency vehicles. The following initiative addresses this 
program area. 


CAD/AVL for Emergency Vehicles (Local Cities/Towns) 


This initiative provides a CAD/AVL system for managing emergency vehicles. This system will 
allow a local or regional emergency dispatch center to track its vehicles in real-time and to 
dispatch those vehicles in the most efficient manner. This initiative will require equipment in each 
vehicle to be tracked, as well as a central system at the dispatch center to receive and manage 
the tracking information. 


6.1.9.3 Transit Safety 


This program area covers the deployment of emergency call boxes at transit facilities. This 
addresses the planned emergency call box elements in the architecture, as well as the interfaces 
with the emergency call centers. The following initiative addresses this program area. 


Emergency Call Boxes (CATA, GATRA, LRTA, MVRTA) 


This initiative comprises the deployment of emergency call boxes at Regional Transit Authority 
facilities. Locations for deployment will include bus stops, terminals, and parking facilities. These 
call boxes will allow a voice connection to security personnel either at RTA control centers or at 
relevant police dispatch centers. They will also support silent alarms, alerting security personnel 
to a problem without the need for voice communications. This initiative will require a 
communications interface between the call boxes and the dispatch center. 


6.1.10 ARCHIVED DATA MANAGEMENT 


6.1.10.1 Planning Data Archive Coordination 


This program area covers the development of interfaces among the planning data archives held by 
transportation agencies in the region. This addresses the planned interfaces between the Office of 
Transportation Planning (OTP) archive and the other databases in the region. The following 
initiative addresses this program area. 


Planning Data Archive 


This initiative consists of the development of a system for coordinating the planning data 
archives for the transportation agencies in the region. The system will provide access to the 
planning data collected by roadway and transit agencies, planning agencies such as the five 
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RPAs and CTPS, and the Registry of Motor Vehicles. As envisioned by the architecture, OTP 
will serve as the regional archived data management system hub, holding information managed 
by OTP as well as providing a portal to the information held by other agencies. This initiative will 
require interfaces between OTP and each of the other participating agencies’ databases. This 
will provide OTP with access to data held by the other agencies, and will provide the other 
agencies with access to data held by OTP. Moreover, this will also provide participating 
agencies with access to each others’ data, allowing one RPA, for example, to access data held 
by an adjacent RPA through the system maintained by OTP. 


6.2 Implementation Strategy 


When implemented, the initiatives identified in the previous section will provide the integrated 
transportation system envisioned by the Regional ITS Architecture. However, due to limitations in 
resources and time, it is not possible to implement of all of these initiatives immediately. Therefore, 
this section recommends a strategy for the implementation of these initiatives, taking into account 
existing agency initiatives and program areas, regional needs, and potential for successful 
implementation. 


Many initiatives in this plan, however, are identified for implementation by a single agency. For 
example, there are a number of initiatives that can be implemented independently by a local city or 
town, such as CAD/AVL for emergency vehicles, CAD/AVL for maintenance vehicles, or variable 
message signs. As these initiatives are independent of any other agency or organization, this 
implementation strategy does not address them. Prioritization of these initiatives will be the 
responsibility of the implementing agency, as only that agency will be able to determine how these 
initiatives fit into its overall capital and operational planning strategies. 


Therefore, this strategy only addresses initiatives that require the participation of multiple agencies 
or organizations. For the purposes of this plan, the multi-agency initiatives have been sorted into 
two categories: “near-term” and “future.” The determination of which group an initiative falls into is 
based on a number of factors. The primary source is the Needs Analysis, presented in Chapter 3, in 
which specific initiatives were identified by agencies as high priority and in which a number of 
critical needs and themes were identified. In addition, initiatives of clear relevance to specific needs 
identified in the needs analysis were also given priority. However, in addition to an initiative’s 
priority and relevance, dependencies between initiatives must also be considered. For example, an 
initiative that has others dependent on its completion should be elevated in priority to avoid delays 
to these other initiatives. 


The recommended “near-term” multi-agency initiatives are presented in Exhibit 6-2. These include 
ones that are currently under development, as well as ones that are not ongoing but are seen as 
critical for the region. 


Exhibit 6-2: Recommended Near-Term Multi-Agency Initiatives 





Functional Area _ | Initiative 





= Event Reporting System 

= Expansion of MIVIS 

Multimodal = Interagency Communications Network 
= 511 Travel Information System 

= Planning Data Archive 





=» Remote MassHighway TOC Workstation (MassHighway and MEMA) 


neraway = Interface between MassHighway TOC and MassPike CA/T OCC 





Transit " Traffic Signal Priority for MBTA Vehicles 
= Logan Parking Management System 


Parking « ETC Integration at MBTA Parking Facilities 
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Specific considerations for each of the initiatives are discussed below: 


The Event Reporting System initiative has been identified as high priority as it addresses 
interagency coordination, a key need identified through the architecture development 
process. In addition, as the system serves as a centralized information repository, it will be 
a source of data for other initiatives, such as the planned 511 Travel Information System 
and the planned Emergency Management Network. Implementation of this initiative, either 
as an expansion of the existing pilot system or as an independent effort, is therefore key to 
moving ahead with these other initiatives. 


The Expansion of MIVIS addresses the need for interagency coordination by allowing the 
sharing of video images among agencies. The initiative also supports emergency 
management, which was identified as another regional need. This system can provide a 
source of data for the proposed 511 Travel Information website and the planned 
Emergency Management Network. Expansion of this system will support the development 
of these other important initiatives. 


The Interagency Communications Network is a high priority initiative because it supports 
the communications requirements of all other initiatives in the Implementation Plan, and is 
especially key for center-to-center coordination needs. It also has the potential to 
significantly reduce agency operational costs through the elimination of leased 
communication lines, which was a key concern that was identified in the needs analysis. 


The 5117 Travel Information System initiative is currently under development. This 
initiative also addresses the need for travel information, another need identified through the 
architecture development process. 


The Planning Data Archive initiative was identified as high-priority because it addresses 
the need for coordination of ITS data for planning purposes. During the architecture 
development process, regional planning stakeholders indicated that data being collected for 
operational purposes would have significant value for planning purposes, but that this data 
was not currently being utilized. 


The initiative to implement a Remote MassHighway TOC Workstation at the MEMA 
operations center is currently under development. This initiative addresses the need for 
center-to-center coordination. It also provides a backup system for emergency operations, 
addressing safety and security needs. 


The initiative to develop an Interface between MassHighway TOC and MassPike CA/T 
OCC was specifically identified as high priority in the needs analysis. It also addresses the 
key need of center-to-center coordination. 


Traffic Signal Priority for the MBTA is an ongoing initiative, currently focused on priority 
for the Silver Line in Boston. This initiative is planned to continue as part of the 
development of the Urban Ring. 


The Logan Parking Management System initiative is currently under development. The 
multi-agency component of this initiative is the integration with MassPike ETC 
transponders. 


The MBTA’s initiative for ETC Integration at Parking Facilities builds on the existing pilot 
project for acceptance of MassPike ETC transponders. 


The remaining multi-agency initiatives are identified as future initiatives and are presented in Exhibit 
6-3. As discussed previously, the determination of the initiatives as “future” rather than “near-term” 
is based primarily on the needs analysis. Therefore, if the needs of the region change, the 
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classification of the initiatives should be reconsidered. For example, if a regional transit agency 
identifies a crucial need for traffic signal priority at a particular intersection, this initiative could be 
implemented in the near-term, as it does not depend on the completion of any other initiatives. If 
other initiatives are related, however, these should be considered. For example, if an RTA wishes 
to move integration of the Regional Fare Card to the near-term, coordination with similar initiatives 
by other RTAs will be a factor. 


As Exhibit 6-3 shows, there are a number of initiatives that are shared by many agencies, such as 
the signal priority and Regional Fare Card integration initiatives. Although not required, coordinated 
implementation of initiatives across these agencies is recommended, since the agencies involved, 
as well as the public, would benefit from the coordinated approach and broad-based deployment. 


Exhibit 6-3: Future Multi-Agency Initiatives 





Functional Area 


Initiative (and Lead Agency) 





Multimodal 


Emergency Management Network 
Regional Fare Card Integration with ETC Transponders 





Transit 


Traffic Signal Priority (BAT, CATA, GATRA, LRTA, MVRTA) 


Regional Fare Card Integration for Transit Vehicles 
(BAT, CATA, GATRA, LRTA, MVRTA, Cities/Towns, Other 
Transit Providers) 





Parking 








ETC Integration at Parking Facilities 
(BTD, Cities/Towns, Massport, Other Parking Operators) 


Regional Fare Card Integration at Parking Facilities 
(BTD, Cities/Towns, Massport, MBTA, Other Parking Operators, 
BAT, CATA, GATRA, LRTA, MVRTA) 
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7. ARCHITECTURE CONSISTENCY AND MAINTENANCE 


The Implementation Plan discussed in the preceding chapter outlines a strategy for implementation 
of the ITS components contained in the architecture. However, it is recognized that in order for ITS 
implementation to be successful, ITS must be integrated into the mainstream transportation 
planning process. This chapter addresses two separate but related issues. The first is ensuring 
that when projects are developed, any ITS elements are consistent with the architecture. The 
second is maintaining the architecture so that it remains relevant and useful to stakeholders in the 
region. Both of these are valuable exercises, and both are also the subject of the federal rules and 
policies governing metropolitan planning. 


As it did for the development of the architecture, the Office of Transportation Planning will take 
responsibility for the oversight of the architecture for Metropolitan Boston. This approach recognizes 
the complexity of coordinating planning across five MPO regions. To be successful, this approach 
will require ongoing information exchange and collaboration among the stakeholders in this region. 


This chapter outlines the approach by which OTP plans — in collaboration with stakeholders in the 
region — to address the federal consistency and maintenance requirements. This approach 
recognizes the importance of integrating ITS planning into the mainstream transportation planning 
process. Therefore, ensuring consistency between projects with ITS elements and the architecture 
is based on the MPO-oriented capital programming process, and maintaining the Regional ITS 
Architecture is designed to be responsive to updates of the long-term regional transportation plans 
and other planning activities. The following sections present the proposed approach. 


7.1 Architecture Consistency 


The United States Department of Transportation is responsible for ensuring that federal 
transportation dollars are used in a manner that is consistent with federal laws and regulations, 
including the Clean Air Act, the Americans with Disabilities Act, and others. As stated in the 2001 
FHWA Rule and FTA Policy: 


“The final design of all ITS projects funded with highways trust funds shall accommodate 
the interface requirements and information exchanges as specified in the regional ITS 
architecture. If the final design of the ITS project is inconsistent with the regional ITS 
architecture, then the regional ITS architecture shall be updated.” 


As with the other federal requirements, this ITS consistency policy means that if agencies seeking 
federal funds want to avoid costly delays during the approval and funding process, they need to be 
sure that the consistency requirement has been met. The objective of the policy is to help an 
agency at the earliest stage possible to realize the opportunities for collaboration with other 
stakeholders, to take advantage of synergies with projects under development at other agencies, 
and to avoid conflicts or duplication of effort. 


The federal regulations also require that all ITS projects be based on a systems engineering 
analysis at a scale commensurate with the project scope, meaning that the more complex the 
project, the more complex the analysis. Such an analysis is typical of any transportation 
engineering project involving the application of advanced technology. While the architecture has 
relevance throughout the project development process, the discussion in this section focuses on the 
initial review for architecture consistency in the early stages of the process. 





3 Federal Highway Administration “Intelligent Transportation System Architecture and Standards; Final Rule” and Federal Transit 
Administration “National ITS Architecture Policy on Transit Projects; Notice” in Federal Register volume 66 number 5, Monday, January 8, 


2001. 
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Since the passage of the Intermodal Surface Transportation Efficiency Act (ISTEA) in 1991, 
transportation planning has been driven by a set of rules governing metropolitan and statewide 
transportation planning. The path that leads from a project concept to federal approval and funding 
goes through two major phases: project initiation and federal approval. The former involves all of 
the work that leads up to submission of a project to a Metropolitan Planning Organization; the latter 
begins with the adoption by that MPO of a fiscally-constrained, prioritized set of projects known as a 
Transportation Improvement Program (TIP), and concludes with federal approval of the state TIP 
(STIP), which is an aggregation of TIPs from around the state, as shown in Exhibit 7-1. The process 
for addressing consistency with the Regional ITS Architecture is designed to fit into this existing 
transportation planning process. As such, this approach relies on existing collaborative 
relationships between each MPO and its local planning partners. 


Project Initiation Federal Approval 








TIPs 


Project = 


Concepts & 


Exhibit 7-1: Project Planning Process 








7.1.1 FEDERAL APPROVAL PHASE 


Because the rule/policy driving this process is focused on the final approval granted by FHWA and 
FTA, the description of the process begins with the federal approval phase. During the federal 
approval phase, each MPO submits its TIP to the state. In Massachusetts, the State Transportation 
Improvement Program (STIP) is an aggregation of the TIPs from around the state and the 
Executive Office of Transportation is responsible for submitting the STIP for approval by FHWA and 
FTA. The approach to addressing the consistency requirement that was developed by the Guidance 
Committee and Project Team was designed to fit into this process. As the discussion of the project 
initiation process explains, a project with ITS elements should not reach the TIP unless consistency 
has been addressed. As a result of addressing the issue before projects reach the TIP, each TIP 
that is submitted to EOT — and by extension the STIP — should be ready for federal approval with 
respect to the consistency issue. 


7.1.2 PROJECT INITIATION PHASE 


The project initiation phase begins with project concepts. By the end of this stage when the TIP is 
being developed, each MPO needs to be certain that the consistency requirement has been 
addressed for all projects that have ITS elements. Each MPO, therefore, will work with its planning 
partners during the project initiation phase, when concepts are being developed for eventual 
inclusion in the TIP, to ensure that the consistency issue is addressed. 


As planning practices vary by region, differences are expected among the MPOs in Massachusetts 
but in general it is expected that the focus will be on whichever agency or entity assumes 
responsibility for a project concept’s development. The role of “project proponent” is often assumed 
by a Regional Transit Authority or MassHighway District office, which often facilitate the 
development of a concept. Consultants and contractors, who often provide extensive technical 
assistance, could also occupy this niche on behalf of their client, as could the individual 
municipalities that often champion specific projects. Regardless of who acts as the project 
proponent, however, the MPO will want to know if a project that has ITS elements is consistent with 
the architecture. Based on input from MPO participants in each region, it is anticipated that this will 
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be handled through the project submission forms employed by each MPO. These forms, which 
document many project attributes, vary among the MPOs. By adding architecture consistency as an 
additional attribute, the MPOs can ensure that the consistency requirement is addressed within 
existing planning practices. 


In this context, it is necessary to differentiate roadway and transit projects, because the paths 
through which they reach the MPO are different in some respects. Transit projects are developed 
and eventually submitted by transit authorities, of which there are seven in the area covered by this 
architecture. Each transit authority develops a list of capital projects, which depend on funds over 
which the MPO has authority. For all kinds of projects but especially for major projects, the 
authorities tend to work closely with the Federal Transit Administration, and proposals are often 
scrutinized closely for various policy issues before they reach the TIP. In most cases, therefore, the 
authority acts as a project proponent. When projects are submitted for inclusion in the TIP, 
regardless of scope or funding type, the transit authority, as project proponent, will document 
whether or not the project has ITS elements and, if it does, that the transit authority affirms that they 
are consistent with the architecture. 


In contrast, aside from major highway improvements, roadway projects tend to begin with an 
advocate such as a city or town within the region proposing an idea to the appropriate 
MassHighway District office. In general, therefore, the Districts will serve as the project proponent 
for most roadway projects from the region that will eventually reach the TIP. When roadway projects 
are submitted for inclusion in the TIP, the District, as the project proponent, will document whether 
or not each project has ITS elements and, if it does, will affirm that they are consistent with the 
architecture. 


For roadway projects, there is another piece of the project initiation phase that happens to benefit 
the consistency requirement. A Project Initiation Form (PIF), required of all project concepts, is 
often drafted by the project advocate and completed by the District, which then submits each PIF to 
a statewide Project Review Committee. This creates an additional opportunity to ensure that the 
project proponent has examined the project for consistency with the architecture. 


This process is illustrated in Exhibit 7-2: 


PROJECT INITIATION PHASE FEDERAL APPROVAL PHASE 








Project Review 
Committee 


cone 


Project Proponent 
(MassHighway District) 











Roadway 


























Metropolitan Executive 
Planning Office of FHWA/ 
Organization Transportation FTA 
(TIP) (STIP) 





























Project Proponent 
Transit (Transit Authority) 
































Exhibit 7-2: Project Initiation and Approval Process 
In addition to this initial review in the early stages of the project development process, consistency 


with the architecture must be revisited as a project develops further in order to ensure that it has not 
been affected by changes to the scope of the project. Moreover, as a project progresses into the 
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design stage, it must undergo a systems engineering analysis, as is typical of ITS projects and as is 
required by the federal Rule and Policy. 


A note about the term “consistency”: 


Because of the superficial similarity to air quality conformity, it is important to clarify the 
differences between the terms consistency and conformity. Whereas air quality goals are 
definitive and fixed, the Regional ITS Architecture is a dynamic product of the transportation 
planning process. The goal of air quality conformity is, in large part, to filter out detrimental 
projects; the intent of the ITS consistency policy is to ensure that when actual projects are 
developed and become candidates for federal funding, the technical and institutional aspects 
are consistent with the architecture. A project may prompt a modification to the architecture, as 
discussed in Section 7.2.2, or may be revised to be consistent with the architecture. As such, 
demonstrating consistency places a great emphasis on considering the relationship between a 
project and the architecture as early and as often as possible. 


7.2 Architecture Maintenance 


Comparable to a Regional Transportation Plan (RTP), the Regional ITS Architecture is a vision of 
the future transportation system, documented at one point in time. The architecture, like an RTP, 
reflects the current situation and documents planned changes or investments. However, in order to 
remain relevant, the architecture has to be maintained. As regional needs evolve, as planned 
elements are deployed, and as other changes occur, the architecture must be updated to reflect 
those developments. Maintenance of the architecture is also motivated by federal requirements that 
require consistency between all federally funded projects with ITS elements and the Regional ITS 
Architecture. 


This section describes how the architecture will be maintained so that it remains relevant to the 
transportation system and useful to planners and operators. The maintenance strategy relies on two 
elements. The first is a formal periodic update at the same frequency as the RTPs, which are 
currently on a three-year update cycle. However, since the RTPs will provide valuable input to the 
architecture, the architecture update process will be staggered to occur after the RTP update. The 
second is interim architecture modifications that may occur at any point in the update cycle, outside 
of the formal update process. This two-pronged approach will have the added benefit of sustaining 
an ongoing region-wide dialogue about ITS. 


The Office of Transportation Planning, which has led the initial development of the Regional ITS 
Architecture, will be responsible for the maintenance of the architecture. However, other 
stakeholders will be involved, as they have been throughout the development process. The 
maintenance strategy describes who will be involved and what responsibilities transportation 
stakeholders in the region should assume. 


7.2.1 PERIODIC ARCHITECTURE UPDATES 


Under this strategy, the Regional ITS Architecture will be formally revisited on the same cycle as 
the Regional Transportation Plan updates (currently every three years), with timing that allows the 
architecture update to take a revised RTP into consideration. In this way, it is expected that the 
revised architecture can incorporate new ideas and/or projects that are included in an updated RTP. 


The Office of Transportation Planning will initiate the Regional ITS Architecture update process with 
a request for information from stakeholders in the region regarding new ITS-related projects, 
initiatives, or needs. OTP will also gather information from the stakeholders in order to evaluate the 
status of the architecture’s implementation, identifying, for example, ITS elements or interfaces that 
have evolved from “planned” to “existing” or that are no longer relevant and should be removed. 
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Based on the information gathered through this process, OTP will generate a draft list of 
architecture modifications and distribute it to the stakeholders for review. OTP can then call a 
stakeholder meeting for the region to review the draft list. This meeting can also provide an 
opportunity to discuss emerging ITS issues. After the stakeholder review of the draft list, OTP will 
make any modifications necessary and release the updated architecture. 


7.2.2 INTERIM ARCHITECTURE MODIFICATIONS 


Just as project developments necessitate TIP amendments, it is anticipated that some modifications 
to the architecture will be needed during the interval between the periodic updates. Therefore, on 
the basis of project developments or other circumstances that require modifications, the project 
proponent will be responsible for drafting an architecture modification proposal and submitting it to 
OTP. The proposal will then be circulated to affected stakeholders for their review. It is expected 
that most architecture modifications, whether periodic or interim, will involve adding new ideas, 
dimensions, or stakeholders to existing market packages, interfaces, or functions. 


7.2.3 SUMMARY 


This maintenance strategy is meant to accomplish several objectives. First, it ensures that the 
architecture will remain current and will reflect the most recent Regional Transportation Plans. 
Second, it allows the architecture to be responsive to changes between updates. And third, it helps 
facilitate an ongoing dialogue about ITS and the implementation of the architecture. Through the 
interim modifications and the periodic updates, this strategy should help to integrate ITS into the 
mainstream transportation planning process. 
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8. CONCLUSION 


8.1 Reasons for the Regional ITS Architecture 


This process of developing a Regional ITS Architecture for Metropolitan Boston has been 
undertaken for a number of reasons. While Federal requirements are certainly a motivating factor, 
there are other objectives that the architecture addresses. 


The first of these objectives is improved interagency coordination. The architecture development 
process addresses this objective not only in the recommendations that have come out of the 
architecture, but also through the process of developing the architecture itself. The establishment 
of the multi-agency stakeholder group that met throughout the architecture development process is 
a significant step towards coordinating ITS planning in the region. The numerous meetings and 
workshops of the Guidance Committee demonstrated the benefit of such a forum to exchange 
information on needs and project plans. The maintenance plan for the architecture offers an 
opportunity for this interaction to continue, with mutual benefits for all of the participants. 


The second objective is cost savings, which is addressed through the recommendations of the 
architecture. For example, coordination of investments and consideration of standards for 
interagency interfaces offer opportunities for cost savings, especially in terms of long-term 
maintenance and operational costs. 


The third objective is better services to the traveling public. The public has the potential to benefit 
from this process, as the architecture addresses needs and priorities that cut across agency lines 
and that are not able to be addressed through single-agency initiatives. The framework outlined by 
the architecture is for a regional transportation system that can provide the public with a seamless 
and consistent travel experience across multiple agency jurisdictions. 


8.2 Architecture Development Approach 


The most critical component of the architecture development process is the participation of the 
region’s stakeholders. The reason that participation is so critical is that stakeholder input is the 
foundation of the architecture. The architecture is not meant to impose a plan for ITS on the region. 
Instead, the architecture builds on the needs of the region, as voiced by the stakeholders. These 
identified needs lead to functional requirements, which in turn lead to recommendations for systems 
and technologies that address these regional needs. However, the architecture is not based solely 
on the needs of the region, as it must also take into consideration the existing systems that must be 
integrated and the plans that agencies have developed. This is yet another reason why 
participation of the stakeholders is essential and why stakeholder involvement was emphasized 
throughout the process. 


The first step in the process, the Needs Analysis, identified these existing systems, plans, and 
needs. Based on this analysis, the ITS architecture was developed, defining the existing and 
planned ITS elements in the region as well as the interfaces among them. The architecture, 
presented interactively on the CD-ROM included in Appendix A, provides a vision of how the ITS 
components in the region will interact to form an integrated transportation system. 


While the architecture addresses what systems will exist and what information they will exchange, it 
does not address how those interfaces will operate and how we move from the current state of 
deployment to the full system envisioned by the architecture. These issues are addressed in the 
Operational Concept and the Implementation Plan, respectively. The Operational Concept 
considers each of the interagency interfaces, including the information to be exchanged and the 
roles of each participant. This provides guidelines for how the interface should operate once it is 
actually implemented and what operational agreements might be necessary. The Implementation 
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Plan considers what steps are necessary in order to fulfill the architecture’s vision, specifically what 
areas of investment are required and what initiatives will need to be undertaken in order to 
implement the component systems of the architecture. 


8.3 Architecture Themes 


Through the development of the architecture, especially in the assessment of needs, a number of 
themes emerged that merited consideration. In the wake of 9/11, a primary overarching theme was 
security. Throughout the architecture development process, links between ITS infrastructure and 
security initiatives were considered. Emergency Management market packages also explicitly 
address safety and security functions. The Implementation Plan also addresses this need through 
the Emergency Management Network initiative, which creates a secure layer to other center-to- 
center initiatives for safety and security usage. 


A second theme was information sharing, specifically the need for better sharing of data and 
information among the region’s agencies and organizations. This theme continued to be prevalent 
throughout the architecture development process, and has been explicitly addressed in its 
recommendations. For example, center-to-center interfaces are key components of the ITS 
Architecture, the Operational Concept, and the Implementation Plan. In the architecture, these are 
addressed in market packages such as Regional Traffic Control and Multimodal Coordination. The 
Operational Concept considers center-to-center interfaces within traffic, transit, and emergency 
management, as well as across the functional jurisdictions. Finally, the Implementation Plan has 
prioritized initiatives such as the event reporting system that address the need for coordination of 
information. 


A third theme was the need for communications infrastructure, weighed against the high costs 
associated with leasing this bandwidth from local telephone providers. As communications 
infrastructure is a requirement for nearly all of the systems in the architecture, this is clearly a 
concern that will continue to grow in importance as systems become implemented. As such, this 
infrastructure requirement is directly addressed in the Implementation Plan, which calls for an 
interagency communications network initiative that supports the infrastructure needs of the 
architecture. 


A final theme was the concerns regarding operations and maintenance, specifically resource 
requirements for these activities. This was addressed in the architecture by focusing on automating 
information flows that currently rely on manual intervention or voice communications. Freeing up 
personnel on these tasks allows more effective use of agency resources. The Operational Concept 
also addresses these issues for the interagency interfaces, laying out the details of each of the 
interface and the roles and responsibilities of each agency. Through this, an agency will be better 
able to plan for the required resources as these interfaces become implemented. 


8.4 Recommendations 


Through the process and from the results of developing the Regional ITS Architecture, including the 
Operational Concept and Implementation Plan, a number of recommendations should be 
considered as the region continues to move forward with deployment of ITS: 


= Of the initiatives in the Implementation Plan, the most critical are the “near-term” multi- 
agency initiatives. Completion of ongoing projects, such as the Event Reporting System and 
the 511 Travel Information System, and implementation of the new initiatives, such as the 
Planning Data Archive and the expansion of MIVIS, are vital for working towards the 
integrated transportation system envisioned by the architecture. Although not as urgent in 
the short term, the remaining “future” multi-agency initiatives are also important in that they 
provide the foundation for interagency coordination throughout the region. 
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«» Formal agreements should be established for the interagency interfaces identified in the 
architecture. This includes existing interfaces as well as new ones. Existing informal 
agreements should be formalized in order to ensure that their benefits are maintained. This 
can be achieved through new agreements that document specific existing working 
arrangements. Operational agreements for new interfaces should be drawn up as these 
new interfaces are established. Proper documentation of the arrangement will be easiest in 
the planning stages and will facilitate implementation and operation in the long term. 


« ITS architecture consistency should be incorporated into the existing MPO transportation 
planning process. While the process outlined in the Implementation Plan identifies the steps 
at which consistency with the architecture will need to be certified, consideration of the 
Regional ITS Architecture throughout the project development process will ensure a 
satisfactory outcome. 


«The Regional ITS Architecture should stay relevant to the region and therefore should be 
updated to reflect the changing needs and priorities of the region. To make this work with 
the existing transportation planning process, it is recommended that the architecture be 
updated regularly to reflect the needs identified in the Regional Transportation Plans in the 
region. In addition, informal updates to ensure consistency with newly proposed projects 
should be done on an as-needed basis. 


«The agencies and organizations that were represented on the Guidance Committee, as well 
as other relevant ITS stakeholders, should continue to meet and remain involved, not only in 
the maintenance of the architecture, but also in coordinating ITS in the region. The benefits 
of this working group that have been realized in the architecture development process 
should be built upon as the transportation system envisioned by the architecture takes 
shape. 


8.5 Using the Architecture 


This process has yielded a valuable tool for planners and operators of the region’s transportation 
system, and there are a number of ways in which the architecture should be used: First, the 
architecture should be used by agencies as a framework for planning ITS projects, as it documents 
what they have planned, as expressed in the architecture development process. If it does not 
reflect the current plans, it should be revised so that it is up to date. 


Second, agencies should use the architecture as a guide to how they should interface with other 
agencies. The ITS architecture documents the interfaces that are planned for development, as well 
as standards that are relevant to these interfaces. In addition, the Operational Concept details the 
operational arrangements that are required for managing these interfaces and provides a model for 
the interagency agreements that should be established. 


Finally, the Regional ITS Architecture provides the basis for satisfying the federal architecture 
consistency requirement for projects with ITS elements. Therefore, it is vital that project proponents 
use the architecture as a guideline during project development, just as the FHWA and FTA will be 
using the architecture when considering whether to approve the project. It is also important that 
consistency with the architecture is revisited throughout the project development process and as 
part of the systems engineering analysis that is required of all ITS projects. Incorporating the 
architecture into the planning, design, and operations process will ensure that all stakeholders in 
the region are moving together towards the vision that they have created through this process. 
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DEPARTMENT OF TRANSPORTATION 


Federal Highway Administration 


23 CFR Parts 655 and 940 
[FHWA Docket No. FHWA-99-5899] 
RIN 2125-AE65 


Intelligent Transportation System 
Architecture and Standards 


AGENCY: Federal Highway 
Administration (FHWA), DOT. 


ACTION: Final rule. 





SUMMARY: The purpose of this document 
is to issue a final rule to implement 
section 5206(e) of the Transportation 
Equity Act for the 21st Century (TEA— 
21), enacted on June 9, 1998, which 
required Intelligent Transportation 
System (ITS) projects funded through 
the highway trust fund to conform to the 
National ITS Architecture and 
applicable standards. Because it is 
highly unlikely that the entire National 
ITS Architecture would be fully 
implemented by any single metropolitan 
area or State, this rule requires that the 
National ITS Architecture be used to 
develop a local implementation of the 
National ITS Architecture, which is 
referred to as a “regional ITS 
architecture.’ Therefore, conformance 
with the National ITS Architecture is 
defined under this rule as development 
of a regional ITS architecture within 
four years after the first ITS project 
advancing to final design, and the 
subsequent adherence of ITS projects to 
the regional ITS architecture. The 
regional ITS architecture is based on the 
National ITS Architecture and consist of 
several parts including the system 
functional requirements and 
information exchanges with planned 
and existing systems and subsystems 
and identification of applicable 
standards, and would be tailored to 
address the local situation and ITS 
investment needs. 

EFFECTIVE DATE: February 7, 2001. 

FOR FURTHER INFORMATION CONTACT: For 
technical information: Mr. Bob Rupert, 
(202) 366-2194, Office of Travel 
Management (HOTM-—1) and Mr. 
Michael Freitas, (202) 366-9292, ITS 
Joint Program Office (HOIT-1). For legal 
information: Mr. Wilbert Baccus, Office 
of the Chief Counsel (HCC-—32), (202) 
366-1346, Federal Highway 
Administration, 400 Seventh Street, 
SW., Washington, DC 20590. Office 
hours are from 8 a.m. to 4:30 p.m., e.t., 
Monday through Friday, except Federal 
holidays. 


SUPPLEMENTARY INFORMATION: 


Electronic Access and Filing 


You may submit or retrieve comments 
online through the Docket Management 
System (DMS) at: http//dmses.dot.gov/ 
submit. Acceptable formats include: MS 
Word (versions 95 to 97), MS Word for 
Mac (versions 6 to 8), Rich Text Format 
(RTF), American Standard Code 
Information Interchange (ASCII) (TXT), 
Portable Document Format (PDF), and 
WordPerfect (version 7 to 8). The DMS 
is available 24 hours each day, 365 days 
each year. Electronic submission and 
retrieval help and guidelines are 
available under the help section of the 
web site. 

An electronic copy of this document 
may be downloaded by using a 
computer, modem, and suitable 
communications software from the 
Government Printing Office’s Electronic 
Bulletin Board Service at (202) 512— 
1661. Internet users may also reach the 
Office of the Federal Register’s home 
page at http://www.nara.gov/fedreg and 
the Government Printing Office’s web 
page at: http://www.access.gpo.gov/ 
nara. The document may also be viewed 
at the DOT’s ITS web page at http:// 
www.its.dot.gov. 


Background 


A notice of proposed rulemaking 
(NPRM) concerning this rule was 
published at 65 FR 33994 on May 25, 
2000, and an extension of the comment 
period to September 23, 2000, was 
published at 65 FR 45942 on July 26, 
2000. 

In the NPRM on this rule, the FHWA 
had proposed that the regional ITS 
architecture follow from the ITS 
integration strategy proposed in another 
NPRM entitled “Statewide 
Transportation Planning; Metropolitan 
Transportation Planning” published at 
65 FR 33922 on May 25, 2000. That rule 
is being developed according to a 
different schedule and will be issued 
separately. For this reason, all 
references to the proposed integration 
strategy have been removed from this 
rule. However, it is still the intent of 
this rule that regional ITS architectures 
be based on established, collaborative 
transportation planning processes. The 
other major changes to the final rule 
relate to options for developing a 
regional ITS architecture and the time 
allowed to develop such an architecture. 
Additional changes to the final rule 
largely deal with clarification of terms, 
improved language dealing with staging 
and grandfathering issues, and 
clarification of use of ITS standards. 

Intelligent Transportation Systems 
represent the application of information 
processing, communications 


technologies, advanced control 
strategies, and electronics to the field of 
transportation. Information technology 
in general is most effective and cost 
beneficial when systems are integrated 
and interoperable. The greatest benefits 
in terms of safety, efficiency, and costs 
are realized when electronic systems are 
systematically integrated to form a 
whole in which information is shared 
with all and systems are interoperable. 

In the transportation sector, 
successful ITS integration and 
interoperability require addressing two 
different and yet fundamental issues; 
that of technical and institutional 
integration. Technical integration of 
electronic systems is a complex issue 
that requires considerable up-front 
planning and meticulous execution for 
electronic information to be stored and 
accessed by various parts of a system. 
Institutional integration involves 
coordination between various agencies 
and jurisdictions to achieve seamless 
operations and/or interoperability. 

In order to achieve effective 
institutional integration of systems, 
agencies and jurisdictions must agree on 
the benefits of ITS and the value of 
being part of an integrated system. They 
must agree on roles, responsibilities, 
and shared operational strategies. 
Finally, they must agree on standards 
and, in some cases, technologies and 
operating procedures to ensure 
interoperability. In some instances, 
there may be multiple standards that 
could be implemented for a single 
interface. In this case, agencies will 
need to agree on a common standard or 
agree to implement a technical 
translator that will allow dissimilar 
standards to interoperate. This 
coordination effort is a considerable task 
that will happen over time, not all at 
once. Transportation organizations, 
such as, transit properties, State and 
local transportation agencies, and 
metropolitan planning organizations 
must be fully committed to achieving 
institutional integration in order for 
integration to be successful. The 
transportation agencies must also 
coordinate with agencies for which 
transportation is a key, but not a 
primary part of their business, such as, 
emergency management and law 
enforcement agencies. 

Successfully dealing with both the 
technical and institutional issues 
requires a high-level conceptual view of 
the future system and careful, 
comprehensive planning. The 
framework for the system is referred to 
as the architecture. The architecture 
defines the system components, key 
functions, the organizations involved, 
and the type of information shared 
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between organizations and parts of the 
system. The architecture is, therefore, 
fundamental to successful system 
implementation, integration, and 
interoperability. 

Additional background information 
may be found in docket number FHWA-— 
99-5899. 


The National ITS Architecture 


The Intermodal Surface 
Transportation Efficiency Act of 1991, 
Public Law 102-240, 105 Stat. 1914, 
initiated Federal funding for the ITS 
program. The program at that time was 
largely focused on research and 
development and operational tests of 
technologies. A key part of the program 
was the development of the National 
ITS Architecture. The National ITS 
Architecture provides a common 
structure for the design of ITS systems. 
The architecture defines the functions 
that could be performed to satisfy user 
requirements and how the various 
elements of the system might connect to 
share information. It is not a system 
design, nor is it a design concept. 
However, it does define the framework 
around which multiple design 
approaches can be developed, each one 
specifically tailored to meet the needs of 
the user, while maintaining the benefits 
of a common approach. 

The National ITS Architecture, 
Version 3.0 can be obtained from the 
ITS Joint Program Office of the DOT in 
CD-ROM format and on the ITS web 
site http://www. its.dot.gov. The effort to 
develop a common national system 
architecture to guide the evolution of 
ITS in the United States over the next 
20 years and beyond has been managed 
since September 1993 by the DOT. The 
National ITS Architecture describes in 
detail what types of interfaces should 
exist between ITS components and how 
they will exchange information and 
work together to deliver the given ITS 
user service requirements. 

The National ITS Architecture and 
standards can be used to guide multi- 
level government and private-sector 
business planners in developing and 
deploying nationally compatible 
systems. By ensuring system 
compatibility, the DOT hopes to 
accelerate ITS integration nationwide 
and develop a strong, diverse 
marketplace for related products and 
services. 

It is highly unlikely that the entire 
National ITS Architecture will be fully 
implemented by any single metropolitan 
area or State. For example, the National 
ITS Architecture contains information 
flows for an Automated Highway 
System that is unlikely to be part of 
most regional implementations. 


However, the National ITS Architecture 
has considerable value as a framework 
for local governments in the 
development of regional ITS 
architectures by identifying the many 
functions and information sharing 
opportunities that may be desired. It can 
assist local governments with both of 
the key elements: technical 
interoperability and institutional 
coordination. 

The National ITS Architecture, 
because it aids in the development of a 
high-level conceptual view of a future 
system, can assist local governments in 
identifying applications that will 
support their future transportation 
needs. From an institutional 
coordination perspective, the National 
ITS Architecture helps local 
transportation planners to identify other 
stakeholders who may need to be 
involved and to identify potential 
integration opportunities. From a 
technical interoperability perspective, 
the National ITS Architecture provides 
a logical and physical architecture and 
process specifications to guide the 
design of a system. The National ITS 
Architecture also identifies interfaces 
where standards may apply, further 
supporting interoperability. 


Transportation Equity Act for the 21st 
Century 


As noted above, section 5206(e) of the 
TEA-—21, Public Law 105-178, 112 Stat. 
457, requires ITS projects funded from 
the highway trust fund to conform to the 
National ITS Architecture, applicable or 
provisional standards, and protocols. 
One of the findings of Congress in 
section 5202 of the TEA—21, is that 
continued investment in systems 
integration is needed to accelerate the 
rate at which ITS is incorporated into 
the national surface transportation 
network. Two of the purposes of the ITS 
program, noted in section 5203(b) of the 
TEA-—21, are to expedite the deployment 
and integration of ITS, and to improve 
regional cooperation and operations 
planning for effective ITS deployment. 
Use of the National ITS Architecture 
provides significant benefits to local 
transportation planners and deployers 
as follows: 

1. The National ITS Architecture 
provides assistance with technical 
design. It saves considerable design time 
because physical and logical 
architectures are already defined. 

2. Information flows and process 
specifications are defined in the 
National ITS Architecture, allowing 
local governments to accelerate the 
process of defining system functionality. 

3. The architecture identifies 
standards that will support 


interoperability now and into the future, 
but it leaves selection of technologies to 
local decisionmakers. 

4. The architecture provides a sound 
engineering framework for integrating 
multiple applications and services in a 
region. 


ITS Architecture and Standards NPRM 
Discussion of Comments 


The FHWA received 105 comments 
on this docket from a wide range of 
stakeholders, including major industry 
associations, State departments of 
transportation, Metropolitan Planning 
Organizations (MPOs), and local 
agencies. The comments were generally 
favorable about the scope and content, 
but requested additional clarification 
and guidance on implementation of 
specific items. On many issues, some 
commenters wanted more specific 
requirements, while others wanted more 
flexibility. Most commenters, including 
major industry associations and public 
sector agencies, agreed with the overall 
scope, but some felt that the specifics 
might be difficult to implement and 
asked for clarification of key terms. A 
few commenters wanted the FHWA to 
reduce the number of requirements or 
convert the rulemaking into a guidance 
activity until more ITS deployment 
experience is gained. 

In summary, the FHWA received a 
large number of generally favorable 
comments about the NPRM that 
suggested minor specific changes and 
expressed a need for further guidance 
on implementation. Since the general 
tenor of the comments was positive, the 
FHWA has kept the scope of the NPRM 
and made appropriate clarifications to 
the text of the final rule to address 
concerns raised in comments. In 
response to the many comments 
requesting it, starting in early 2001, the 
FHWA will also provide a program of 
guidance, training, and technical 
support to assist with the 
implementation of this rule. The 
following is a detailed discussion of the 
comments and their disposition, 
organized by subject matter. 


Section 940.3 Definitions 


ITS Project. There were 34 comments 
submitted to the docket concerning the 
definition of an ITS project. Many of the 
commenters felt the definition was not 
clear enough, was too broad, or was too 
subject to interpretation. Some 
comments questioned how much of a 
project’s budget would have to be spent 
on ITS before a project would be 
considered an ITS project. Some 
suggested specific language to more 
narrowly define an ITS project by 
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focusing on the portion of the overall 
project that is actually ITS or by 
suggesting language that would narrow 
the definition of an ITS project to only 
include projects which introduce new 
or changed integration opportunities. 

Since the intent of this rule and the 
supporting legislation is to facilitate the 
deployment of integrated ITS systems, it 
is the position of the FHWA that the 
definition of an ITS project must be 
fairly broad to include any ITS system 
being funded with highway trust fund 
dollars. It is only by properly 
considering all planned ITS investments 
in the development of a regional ITS 
architecture that the integration 
opportunities and needs can even be 
identified. This consideration should be 
carried out in the development of an 
architecture prior to the specific project 
being advanced. If, in the development 
of a regional ITS architecture, it is 
determined that a specific planned 
project offers no real integration 
opportunities for the region, then the 
impact of this rule on that specific 
project is minimal. 

As a response to the comments 
concerning the clarity of the definition, 
the definition of an ITS project has been 
slightly modified to remove the 
examples since they were considered 
misleading. The FHWA recognizes that 
any definition will be subject to 
interpretation by the stakeholders and 
acknowledges the need for guidance in 
this area to ensure clear and consistent 
interpretation of this rule. Guidance on 
what constitutes an ITS project 
(including examples) will be developed 
to assist the various stakeholders, 
including the FHWA Division Offices, 
to better understand what projects 
should be considered ITS projects. 

Region. There were 26 comments 
submitted related to the definition of a 
region. Seven comments supported the 
open definition provided in the NPRM, 
arguing that the possible integration 
opportunities in an area should define 
the region and that there were too many 
possible variations to allow a restrictive 
definition. Six commenters who 
expressed concern over varying 
conditions interpreted the definition to 
mean Metropolitan Planning Area 
(MPA). Five comments suggested an 
MPA was too restrictive. Eight other 
comments indicated that the proposed 
definition of a region did not clearly 
identify what entity would have the 
lead in developing a regional ITS 
architecture or thought the definition 
implied the MPO should have the lead. 
Nine comments suggested various limits 
or boundaries to fit specific situations. 
Ten comments expressed a need for 


greater clarification of the definition for 
a region. 

The intent of the proposed definition 
was to allow considerable flexibility on 
the part of the stakeholders in defining 
the boundaries of a region to best meet 
their identified integration 
opportunities. While there was no intent 
to generally restrict the definition to 
MPAs or States, the FHWA determined 
that regional ITS architectures should be 
based on an integration strategy that was 
developed by an MPO or State as part 
of its transportation pean process. 

Given that the final rule does not 
require or reference an integration 
strategy, the FHWA feels a need to 
provide more specific guidance on the 
definition of a region. As such, the 
definition of a region has been revised 
to indicate that the MPA should be the 
minimum area considered when 
establishing the boundaries of a region 
for purposes of developing a regional 
ITS architecture within a metropolitan 
area. This should not be interpreted to 
mean that a region must be an MPA, or 
no less than an MPA, but the MPA and 
all the agencies and jurisdictions within 
the MPA should be at least considered 
for inclusion in the process of 
developing a regional ITS architecture 
within a metropolitan area. This rule is 
silent on other possible limits or 
minimum areas for defining a region, 
relying on the flexible nature of this rule 
to accommodate those special 
circumstances. The FHWA also 
acknowledges it is possible that 
overlapping regions could be defined 
and overlapping regional ITS 
architectures be developed to meet the 
needs of the regions. 

Other Definitions. There were 20 
comments suggesting that other terms 
used in the NPRM be defined. These 
included “‘interoperability,”’ 
“standards,” “concept of operations,” 
“conceptual design,” and “integration 
strategy.’’ Several of these are no longer 
used in the final rule and, therefore, 
were not defined. Other terms, such as 
“interoperability” and “standards,” 
were determined to be common terms 
whose definition did not effect the 
implementation of the final rule. 
Furthermore, language regarding 
standards conformity has been clarified 
in the body of the final rule. 


Section 940.5 Policy 


Twenty-eight commenters addressed 
the issue of consistency between the 
two related FHWA notices of proposed 
rulemaking (23 CFR parts 940 and 1410) 
and the Federal Transit 
Administration’s (FTA) notice (FTA 
Docket No. FTA—99-6417) on National 
ITS Architecture published at 65 FR 


34002 on May 25, 2000. The comments 
revealed a lack of understanding about 
the relationship between the regional 
ITS architecture and the integration 
strategy proposed as part of the 
revisions to FHWA’s transportation 
planning rules. There were five 
comments suggesting a single DOT rule 
addressing how all ITS projects would 
meet the National ITS Architecture 
conformance requirements of the TEA— 
21 instead of an FHWA rule for highway 
projects and an FTA policy for transit 
projects. Four other comments 
acknowledged the need for two policies, 
but recommended they articulate the 
same process. 

A final transportation planning rule is 
being developed on a different schedule 
than this rule, and comments regarding 
the portions of the National ITS 
Architecture conformity process 
included in the transportation planning 
rule will be addressed as it proceeds 
toward issuance. The FHWA and FTA 
have chosen to go forward with policies 
that have been developed cooperatively 
to implement the National ITS 
Architecture conformance process. This 
FHWA rule and the parallel FTA policy 
have been developed without reference 
to the proposed changes to the 
transportation planning process, 
including no mention of the 
development of an integration strategy. 
However, the policy statement of this 
rule notes a link to established 
transportation planning processes, as 
provided under 23 CFR part 450. This 
rule fully supports these collaborative 
methods for establishing transportation 
goals and objectives, and does not 
provide a mechanism for introducing 
projects outside of the transportation 
planning processes. 

This final rule on National ITS 
Architecture conformance and the FTA 
policy on the same subject have been 
developed cooperatively and 
coordinated among the agencies to 
ensure compatible processes. Any 
differences between this rule and the 
parallel FTA policy are intended to 
address differences in highway and 
transit project development and the way 
the FHWA and the FTA administer 
projects and funds. 

Fifteen commenters questioned the 
need for an integration strategy, and the 
relationship between the strategy and 
the regional ITS architecture. 

Given the fact that proposed revisions 
to the FHWA’s transportation planning 
rules are being developed according to 
a different schedule, this rule has been 
revised to remove any references to an 
integration strategy. Comments 
regarding the integration strategy will be 
addressed in the final transportation 
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planning rule, and the discussion of the 
regional ITS architecture in § 940.9 has 
been revised to clarify its content. 


Section 940.7 Applicability 


A few commenters noted that the 
proposed rule had not addressed the 
TEA-—21 language that allows for the 
Secretary to authorize certain 
exceptions to the conformity provision. 
These exceptions relate to those projects 
designed to achieve specific research 
objectives or, if three stated criteria are 
met, to those intended to upgrade or 
expand an ITS system in existence on 
the date of enactment of the TEA—21. 
The legislation also included a general 
exemption for funds used strictly for 
operations and maintenance of an ITS 
system in existence on the date of 
enactment of the TEA-21. 

The FHWA acknowledges this 
omission and has included the 
appropriate language in this section of 
the rule. 


Section 940.9 Regional ITS 
Architecture 


Several comments were received 
related to the way the proposed rule 
referred to developing regional ITS 
architectures. Eight comments, from 
State agencies and metropolitan 
planning organizations, supported an 
incremental approach to developing 
regional ITS architectures, starting with 
project ITS architectures and building 
them together. Four other comments, 
from metropolitan planning 
organizations and industry associations, 
noted that an ad hoc regional ITS 
architecture developed incrementally 
through projects would result in an 
architecture less robust than if there 
were a single, initial effort to develop it. 

Also, thirteen comments from the 
Association of American State Highway 
and Transportation Officials (AASHTO) 
and a number of States recommended 
extending the time for developing 
regional ITS architectures, as the 
proposed two year implementation 
would be too short. Ten of the 
commenters preferred four years in 
order to acquire the necessary resources 
for developing regional ITS 
architectures. 

Most commenters were in agreement 
with the content of the regional ITS 
architecture as defined in the proposed 
rule. However, there were 19 comments 
that dealt with confusion over the 
definition of both “conceptual design” 
and ‘“‘concept of operations.” In 
addition, there were 17 other comments 
on the makeup of the stakeholders, 
involvement of the private sector, and 
the need and desirability of 
“agreements” between stakeholders. 


The comments indicated confusion 
regarding the development of regional 
ITS architectures, and especially so in 
discussing the period of time for their 
development. Therefore, the final rule 
has clarified the time period for 
developing regional ITS architectures by 
adopting the proposed extension to four 
years subsequent to beginning to deploy 
ITS projects (§ 940.9(c)), or four years 
from the effective date of this rule for 
those areas that are currently deploying 
ITS projects (§ 940.9(b)). In clarifying 
the time for development, this rule has 
eliminated any references to specific 
methods for developing regional ITS 
architectures. By not prescribing any 
methods, the rule provides flexibility to 
a region in deciding how it should 
develop its regional ITS architecture. 
Guidance and information related to 
developing regional ITS architectures is 
available from FHWA Division Offices 
and from the ITS web site, http:// 
www.its.dot.gov, and will be expanded 
to provide assistance in meeting the 
intent of the rule. 

Both the terms “conceptual design” 
and ‘‘concept of operations” have been 
deleted from the final rule. In their stead 
are descriptions of the content that is 
expected to form the basis for a regional 
ITS architecture. This content has not 
significantly changed from that defined 
in the NPRM but is now contained in 
§ 940.9(d). The level of detail required is 
to the architecture flow level as defined 
in the National ITS Architecture. The 
regional ITS architecture must identify 
how agencies, modes, and systems will 
interact and operate if the architecture 
is to fulfill the objective of promoting 
ITS integration within a region. 

The relevant stakeholders for a region 
will vary from region to region. The list 
articulated in § 940.9(a) is representative 
only and not meant to be inclusive or 
exclusive. On the specific issue of 
private sector participation, if the 
private sector is deploying ITS systems 
in a region or otherwise providing an 
ITS-based service, it would be 
appropriate to engage them in the 
development of a regional ITS 
architecture. Because of these variations 
from region to region, the FHWA felt it 
inappropriate to attempt to define an all 
inclusive list of stakeholders. The group 
of relevant stakeholders will be a 
function of how the region is defined 
and how transportation services are 
provided to the public. Section 
940.9(d)(4) specifies that in the 
development of the regional ITS 
architecture, it shall include ‘‘any 
agreements (existing or new) required 
for operations.’ The formalization of 
these types of agreements is at the 


discretion of the region and 
participating stakeholders. 

There were 14 comments from a broad 
range of organizations questioning how 
existing regional ITS architectures, 
strategic plans or ITS Early Deployment 
Plans would be treated under this rule. 
It is the intent of the FHWA that any 
existing ITS planning documents should 
be used to the extent practical to meet 
the requirements of this rule. Ifa 
regional ITS architecture is in place, is 
up to date, and addresses all the 
requirements of a regional ITS 
architecture as described in this rule, 
there is no requirement to develop a 
“new” one. If the existing regional ITS 
architecture does not address all the 
requirements of the rule, it may be 
possible to update it so that it meets the 
regional ITS architecture requirements 
of this rule. What is necessary is that the 
end result is an architecture that meets 
the requirements of this rule and 
properly addresses the ITS deployments 
and integration opportunities of that 
region. This issue is specifically 
addressed in § 940.9(e) of this rule. 

There were five comments related to 
the impact of this rule on legacy systems 
(i.e., ITS systems already in place) and 
requesting some sort of 
“erandfathering” for them. The language 
in § 940.11(g) of the final rule clarifies 
the grandfathering or staging aspects of 
the process. The final rule does not 
require any changes or modifications to 
existing systems to conform to the 
National ITS Architecture. It is very 
likely that a regional ITS architecture 
developed by the local agencies and 
other stakeholders would call for 
changes to legacy systems over time to 
support desired integration. However, 
such changes would not be required by 
the FHWA; they would be agreed upon 
by the appropriate stakeholders as part 
of the development of the regional ITS 
architecture. 

There were 15 comments dealing with 
the maintenance process and status of 
the National ITS Architecture. Two 
comments suggested the need for the 
FHWA to formally adopt the National 
ITS Architecture. Four other comments 
also supported the formalization of a 
process for maintaining or updating it 
with the full opportunity for public 
input. 

Conformance with the National ITS 
Architecture is interpreted to mean the 
use of the National ITS Architecture to 
develop a regional ITS architecture, and 
the subsequent adherence of all ITS 
projects to that regional ITS 
architecture. This rule requires that the 
National ITS Architecture be used as a 
resource in developing a regional ITS 
architecture. 
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As a technical resource, it is 
important that the National ITS 
Architecture be maintained and updated 
as necessary in response to user input 
or to add new user services, but formal 
adoption of the National ITS 
Architecture is not necessary. However, 
the FHWA recognizes the need to 
maintain the National ITS Architecture 
and to establish an open process for 
configuration control that includes 
public participation. The process 
currently used by the DOT to maintain 
the National ITS Architecture is very 
rigorous and involves significant public 
participation. That process is currently 
being reviewed by the DOT with the 
intent of establishing a configuration 
management process that engages the 
public at key stages and ensures a 
consensus for updating the National ITS 
Architecture. 

Four comments suggested that this 
rule should not be implemented until 
the National ITS Architecture was 
complete. The National ITS 
Architecture will never stop evolving 
since there always is a potential need to 
regularly update it as more is learned 
about ITS deployment. The FHWA 
believes the National ITS Architecture is 
developed to a stage where it can be 
used as a resource in developing 
regional ITS architectures, as required 
by this rule. 

Seventeen comments asked the 
FHWA to define the agency that is 
responsible for the development and 
maintenance of the regional ITS 
architecture; specifically MPOs and/or 
the State as those entities that are 
already responsible for the planning 
process. 

The FHWA did not define the 
responsibility for either creating or 
maintaining the regional ITS 
architecture to a specific entity because 
of the diversity of transportation 
agencies and their roles across the 
country. It is recognized that in some 
regions traditional State and MPO 
boundaries may not meet the needs of 
the traveling public or the 
transportation community. This is also 
why the FHWA did not rigidly define a 
region. The FHWA encourages MPOs 
and States to include the development 
of their regional ITS architectures as 
part of their transportation planning 
processes. However, the decision is best 
left to the region to determine the 
approach that best reflects their needs, 
as indicated in § 940.9. It is clear that 
the value of a regional ITS architecture 
will only be realized if that architecture 
is maintained through time. However, in 
accepting Federal funds under title 23, 
U.S.C., the State is ultimately 
responsible for complying with Federal 


requirements, as provided in 23 U.S.C. 
106 and 133. 

Four commenters noted that the 
proposed rule did not adequately 
address planning for, or committing to, 
a defined level of operations and 
maintenance. 

The final rule addresses this concern 
on two primary levels, in the 
development of the regional ITS 
architecture and the development of 
individual projects. Section 940.9(d)(4) 
specifies that in the development of the 
regional ITS architecture, it shall 
include “any agreements (existing or 
new) required for operations.” The 
formalization of these types of 
agreements is at the discretion of the 
region and participating stakeholders. 

Also, relative to operations and 
management at a project level, 

§ 940.11(c)(7) specifies that the systems 
engineering analysis (required of all ITS 
projects) includes ‘“‘procedures and 
resources necessary for the operations 
and management of the system.”’ 


Section 940.11 Project Implementation 


In addition to the comments on 
regional ITS architecture development 
noted above, the docket received 86 
comments on systems engineering and 
project implementation. These 
comments revealed that the structure of 
the NPRM in discussing regional ITS 
architecture development, project 
systems engineering analysis, and 
project implementation was confusing 
and difficult to read. 

To clarify these portions of the rule, 
the systems engineering and project 
implementation sections of the NPRM 
have been combined into § 940.11, 
Project Implementation. Also, 
paragraphs that were in the regional ITS 
architecture section of the NPRM that 
discussed major ITS projects and the 
requirements for developing project 
level ITS architectures have been 
rewritten to clarify their applicability. 
Since these paragraphs deal with project 
development issues, they have been 
moved to § 940.11(e). A definition for 
“project level ITS architecture” was 
added in § 940.3 and a description of its 
contents provided in § 940.11(e). 

The docket received 33 comments 
regarding systems engineering and the 
systems engineering analysis section of 
the proposed rule. Most of the 
comments related to the definition, the 
process not being necessary except for 
very large projects, and confusion as to 
how these requirements relate to 
existing FHWA policy. 

In response to the docket comments, 
the definition of systems engineering in 
§ 940.3 has been clarified and is more 
consistent with accepted practice. In 


order to provide consistency in the 
regional ITS architecture process, the 
systems engineering analysis detailed in 
§§ 940.11(a) through 940.11(c) must 
apply to all ITS projects regardless of 
size or budget. However, the analysis 
should be on a scale commensurate with 
project scope. To allow for the greatest 
flexibility at the State and local level, in 
§ 940.11(c), a minimum number of 
elements have been clearly identified 
for inclusion in the systems engineering 
analysis. Many of those elements are 
currently required as provided in 23 
CFR 655.409, which this rule replaces. 
Recognizing the change in some current 
practices this type of analysis will 
require, the FHWA intends to issue 
guidance, training, and technical 
support in early 2001 to help 
stakeholders meet the requirements of 
the final rule. 

Fifty-three comments were submitted 
regarding ITS standards and 
interoperability tests. The commenters 
expressed concern about requiring the 
use of ITS standards and 
interoperability tests prematurely, the 
impact on legacy systems of requiring 
ITS standards, and confusion regarding 
the term ‘‘adopted by the DOT.” 

In response to the comments, the 
FHWA has significantly modified the 
final rule to eliminate reference to the 
use of standards and interoperability 
tests prior to adoption in § 940.11(f). 
Section 940.11(g) addresses the 
applicability of standards to legacy 
systems. It is not the intent of the DOT 
to formally adopt any standard before 
the standard is mature; and also, not all 
ITS standards should, or will, be 
formally adopted by the DOT. Formal 
adoption of a standard means that the 
DOT will go through the rulemaking 
process, including a period of public 
comment, for all standards that are 
considered candidates for adoption. 

The DOT has developed a set of 
criteria to determine when a standard 
could be considered for formal 
adoption. These criteria include, at a 
minimum, the following elements: 

1. The standard has been approved by 
a Standard Development Organization 
(SDO). 

2. The standard has been successfully 
tested in real world applications as 
appropriate. 

3. The standard has received some 
degree of acceptance by the community 
served by the standard. 

4. Products exist to implement the 
standard. 

5. There is adequate documentation to 
support the use of the standard. 

6. There is training available in the 
use of the standard where applicable. 
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Therefore, the intent of the rule is to 
require the use of a standard only when 
these criteria have been met, and there 
has been a separate rulemaking on 
adoption of the standard. 

The only interoperability tests that are 
currently contemplated by the DOT are 
those associated with the Commercial 
Vehicle Operations (CVO) program. 
These tests are currently being used by 
States deploying CVO systems and will 
follow a similar set of criteria for 
adoption as those defined for standards. 


Section 940.13 Project Administration 


There were nine comments related to 
how conformity with the final rule 
would be determined, and by whom. 
There were 11 comments about how 
conformity with the regional ITS 
architecture would be determined, and 
by whom. Six comments specifically 
suggested methods for determining 
conformance, including a process 
similar to current Federal planning 
oversight procedures. Six other 
commenters suggested that 
determination be made by the MPO or 
State. For either case, the comments 
reflected a lack of clarity as to what 
documentation would be necessary. 
There were six related comments 
suggesting the level of documentation 
be commensurate with the scale of the 
planned ITS investments in the region. 

In § 940.13 of the final rule, the 
FHWA has attempted to clarify the 
process for determining conformance. 
Conformance of an ITS project with a 
regional ITS architecture shall be made 
prior to authorization of funding for 
project construction or implementation 
as provided in 23 U.S.C. 106 and 133. 
We do not intend to create new 
oversight procedures beyond those 
provided in 23 U.S.C. 106 and 133, but 
in those cases where oversight and 
approval for ITS projects is assumed by 
the State, the State will be responsible 
for ensuring compliance with this 
regulation and the FHWA’s oversight 
will be through existing processes. 

There were 14 comments concerning 
the documentation requirements of the 
proposed rule and generally suggesting 
they be reduced. Certainly the 
development of a regional ITS 
architecture and evidence of 
conformance of a specific project to that 
regional ITS architecture implies some 
level of documentation be developed. 
However, to allow flexibility on the part 
of the State or local agency in 
demonstrating compliance with the 
final rule, no specific documentation is 
required to be developed or submitted 
to the FHWA for review or approval. 
The FHWA recognizes the need to be 
able to scale the regional ITS 


architecture and the associated 
documentation to the needs of the 
region. Section 940.9(a) of the final rule 
contains specific language allowing 
such scaling. 


Summary of Requirements 


I. The Regional ITS Architecture 


This final rule on the ITS Architecture 
and Standards requires the development 
of a local implementation of the 
National ITS Architecture referred to as 
a regional ITS architecture. The regional 
ITS architecture is tailored to meet local 
needs, meaning that it does not address 
the entire National ITS Architecture and 
can also address services not included 
in the National ITS Architecture. The 
regional ITS architecture shall contain a 
description of the region and the 
identification of the participating 
agencies and other stakeholders; the 
roles and responsibilities of the 
participating agencies and other 
stakeholders; any agreements needed for 
operation; system functional 
requirements; interface requirements 
and information exchanges with 
planned and existing systems; 
identification of applicable standards; 
and the sequence of projects necessary 
for implementation. Any changes made 
in a project design that impact the 
regional ITS architecture shall be 
identified and the appropriate revisions 
made and agreed to in the regional ITS 
architecture. 

Any region that is currently 
implementing ITS projects shall have a 
regional ITS architecture within four 
years of the effective date of this rule. 
All other regions not currently 
implementing ITS projects shall have a 
regional ITS architecture within four 
years of the first ITS project for that 
region advancing to final design. In this 
context, a region is a geographical area 
that is based on local needs for sharing 
information and coordinating 
operational strategies among multiple 
projects. A region can be specified at a 
metropolitan, Statewide, multi-State, or 
corridor level. Within a metropolitan 
area, the metropolitan planning area 
should be the minimum area that is 
considered when establishing the 
boundaries of a region for purposes of 
developing a regional ITS architecture. 
A regional approach promotes 
integration of transportation systems. 
The size of the region should reflect the 
breadth of the integration of 
transportation systems. 


II. Project Development 


Additionally, this rule requires that 
all ITS projects be developed using a 
systems engineering analysis. All ITS 


projects that have not yet advanced to 
final design are required to conform to 
the system engineering requirements in 
§ 940.11 upon the effective date of this 
rule. Any ITS project that has advanced 
to final design by the effective date of 
this rule is exempt from the 
requirements of § 940.11. When the 
regional ITS architecture is completed, 
project development will be based on 
the relevant portions of it which the 
project implements. Prior to completion 
of the regional ITS architecture, major 
ITS projects will develop project level 
ITS architectures that are coordinated 
with the development of the regional 
ITS architecture. ITS projects will be 
required to use applicable ITS standards 
and interoperability tests that have been 
officially adopted by the DOT. Where 
multiple standards exist, it will be the 
responsibility of the stakeholders to 
determine how best to achieve the 
interoperability they desire. 


Rulemaking Analyses and Notices 


Executive Order 12866 (Regulatory 
Planning and Review) and DOT 
Regulatory Policies and Procedures 


The FHWA has determined that this 
action is not a significant regulatory 
action within the meaning of Executive 
Order 12866 or significant within the 
meaning of the Department of 
Transportation’s regulatory policies and 
procedures. It is anticipated that the 
economic impact of this rulemaking will 
be minimal. This determination is based 
upon preliminary and final regulatory 
assessments prepared for this action that 
indicate that the annual impact of the 
rule will not exceed $100 million nor 
will it adversely affect the economy, a 
sector of the economy, productivity, 
jobs, the environment, public health, 
safety, or State, local, or tribal 
governments. In addition, the agency 
has determined that these changes will 
not interfere with any action taken or 
planned by another agency and will not 
materially alter the budgetary impact of 
any entitlements, grants, user fees, or 
loan programs. Copies of the 
preliminary and final regulatory 
assessments are included in the docket. 


Costs 


The FHWA prepared a preliminary 
regulatory evaluation (PRE) for the 
NPRM and comments were solicited. 
That analysis estimated the total costs of 
this rule over 10 years to be between 
$38.1 million and $44.4 million (the net 
present value over 10 years was between 
$22.3 million and $31.2 million). The 
annual constant dollar impact was 
estimated to range between $3.2 million 
and $4.4 million. We believe that the 
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cost estimates as stated in the PRE are 
negligible. The FHWA received only 
one comment in response to the PRE. 
That commenter, the Capital District 
Transportation Committee of Albany, 
New York suggested that our cost 
estimates were too low, but provided no 
further detail or rationale which would 
cause us to reconsider or increase our 
cost estimates in the initial regulatory 
evaluation. 

These 10-year cost estimates set forth 
in the PRE included transportation 
planning cost increases, to MPOs 
ranging from $10.8 million to $13.5 
million, and to States from $5.2 million 
to $7.8 million associated with our 
initial requirement to develop an ITS 
integration strategy that was proposed 
as part of the metropolitan and 
statewide planning rulemaking effort. 
The agency now plans to advance that 
proposed ITS integration strategy in the 
planning rule on a different time 
schedule than this final rule. Thus, the 
costs originally set forth in the PRE for 
the ITS integration strategy have been 
eliminated from the final cost estimate 
in the final regulatory evaluation (FRE) 
for this rule. 

In the FRE, the agency estimates the 
cost of this rule to be between $1 
million an $16 million over ten years, 
which are the estimated costs of this 
rule to implementing agencies for the 
development of the regional ITS 
architectures. These costs do not 
include any potential additional 
implementation costs for individual 
projects which are expected to be 
minimal and were extremely difficult to 
estimate. Thus, the costs to the industry 
are less than that originally estimated in 
the agency’s NPRM. 


Benefits 


In the PRE, the FHWA indicated that 
the non-monetary benefits derived from 
the proposed action included savings 
from the avoidance of duplicative 
development, reduced overall 
development time, and earlier detection 
of potential incompatibilities. We stated 
that, as with project implementation 
impacts, the benefits of the rule are very 
difficult to quantify in monetary terms. 
Thus, we estimated that the 
coordination guidance provided through 
implementation of the rule could 
provide savings of approximately 
$150,000 to any potential entity seeking 
to comply with the requirements of 
section 5206(e) of the TEA—21 as 
compared with an entity having to 
undertake compliance individually. The 
costs may be offset by benefits derived 
from the reduction of duplicative 
deployments, reduced overall 


development time, and earlier detection 
of potential incompatibilities. 

In developing a final regulatory 
evaluation for this action, we did not 
denote a significant change in any of the 
benefits anticipated by this rule. This is 
so notwithstanding the fact that our 
planning costs for the ITS integration 
strategy have been eliminated from the 
final cost estimate. The primary benefits 
of this action that result from avoidance 
of duplicative development, reduced 
overall development time, and earlier 
detection of potential incompatibilities 
will remain the same. 

In sum the agency believes that the 
option chosen in this action will be 
most effective at helping us to 
implement the requirements of section 
5206(e) of the TEA—21. In developing 
the rule, the FHWA has sought to allow 
broad discretion to those entities 
impacted, in levels of response and 
approach that are appropriate to 
particular plans and projects, while 
conforming to the requirements of the 
TEA-21. The FHWA has considered the 
costs and benefits of effective 
implementation of ITS through careful 
and comprehensive planning. Based 
upon the information above, the agency 
anticipates that the economic impact 
associated with this rulemaking action 
is minimal and a full regulatory 
evaluation is not necessary. 


Regulatory Flexibility Act 


In compliance with the Regulatory 
Flexibility Act (5 U.S.C. 601-612), the 
FHWA has evaluated, through the 
regulatory assessment, the effects of this 
action on small entities and has 
determined that this action will not 
have a significant economic impact on 
a substantial number of small entities. 
Small businesses and small 
organizations are not subject to this rule, 
which applies to government entities 
only. Since § 940.9(a) of this rule 
provides for regional ITS architectures 
to be developed on a scale 
commensurate with the scope of ITS 
investment in the region, and 
§ 940.11(b) provides for the ITS project 
systems engineering analysis to be on a 
scale commensurate with the project 
scope, compliance requirements will 
vary with the magnitude of the ITS 
requirements of the entity. Small, less 
complex ITS projects have 
correspondingly small compliance 
documentation requirements, thereby 
accommodating the interest of small 
government entities. Small entities, 
primarily transit agencies, are 
accommodated through these scaling 
provisions that impose only limited 
requirements on small ITS activities. 
For these reasons, the FHWA certifies 


that this action will not have a 
significant impact on a substantial 
number of small entities. 


Unfunded Mandates Reform Act of 
1995 


This action does not impose 
unfunded mandates as defined by the 
Unfunded Mandates Reform Act of 1995 
(Pub. L. 104—4, March 22, 1995, 109 
Stat. 48). This rule will not result in an 
expenditure by State, local, and tribal 
governments, in the aggregate, or by the 
private sector, of $100 million or more 
in any one year. 


Executive Order 13132 (Federalism) 


This action has been analyzed in 
accordance with the principles and 
criteria contained in Executive Order 
13132, dated August 4, 1999, and the 
FHWA has determined that this action 
does not have sufficient federalism 
implications to warrant the preparation 
of a federalism assessment. The FHWA 
has also determined that this action 
does not preempt any State law or State 
regulation or affect the State’s ability to 
discharge traditional State governmental 
functions. 


Executive Order 12372 
(Intergovernmental Review) 


Catalog of Federal Domestic 
Assistance Program Number 20.205, 
Highway planning and construction. 
The regulations implementing Executive 
Order 12372 regarding 
intergovernmental consultation on 
Federal programs and activities apply to 
this program. 


Paperwork Reduction Act of 1995 


This action does not contain 
information collection requirements for 
the purposes of the Paperwork 
Reduction Act of 1995, 44 U.S.C. 3501-— 
3520. 


Executive Order 12988 (Civil Justice 
Reform) 


This action meets applicable 
standards in sections 3(a) and 3(b)(2) of 
Executive Order 12988, Civil Justice 
Reform, to minimize litigation, 
eliminate ambiguity, and reduce 
burden. 


Executive Order 13045 (Protection of 
Children) 


We have analyzed this action under 
Executive Order 13045, Protection of 
Children from Environmental Health 
Risks and Safety Risks. This rule is not 
an economically significant rule and 
does not concern an environmental risk 
to health or safety that may 
disproportionately affect children. 
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Executive Order 12630 (Taking of 
Private Property) 


This rule does not effect a taking of 
private property or otherwise have 
taking implications under Executive 
Order 12630, Government Actions and 
Interference with Constitutionally 
Protected Property Rights. 


National Environmental Policy Act 


The agency has analyzed this action 
for the purposes of the National 
Environmental Policy Act of 1969, as 
amended (42 U.S.C. 4321-4347), and 
has determined that this action will not 
have any effect on the quality of the 
environment. 


Regulation Identification Number 


A regulation identification number 
(RIN) is assigned to each regulatory 
action listed in the Unified Agenda of 
Federal Regulations. The Regulatory 
Information Service Center publishes 
the Unified Agenda in April and 
October of each year. The RIN contained 
in the heading of this document can be 
used to cross reference this proposed 
action with the Unified Agenda. 


List of Subjects 
23 CFR Part 655 


Design standards, Grant programs- 
transportation, Highways and roads, 
Incorporation by reference, Signs and 
symbols, Traffic regulations. 


23 CFR Part 940 


Design standards, Grant programs- 
transportation, Highways and roads, 
Intelligent transportation systems. 


Issued on: January 2, 2001. 
Kenneth R. Wykle, 
Federal Highway Administrator. 


In consideration of the foregoing, the 
FHWA amends Chapter I of title 23, 
Code of Federal Regulations, as set forth 
below: 


PART 655—[AMENDED] 


1. The authority citation for part 655 
continues to read as follows: 


Authority: 23 U.S.C. 101(a), 104, 109(d), 
114(a), 217, 315, and 402(a); 23 CFR 1.32, 
and 49 CFR 1.48(b). 


Subpart D—[Removed and reserved] 


2. Remove and reserve subpart D of 
part 655, consisting of §§ 655.401, 
655.403, 655.405, 655.407, 655.409, 
655.411. 


3. Add a new subchapter K, consisting 
of part 940, to read as follows: 


Subchapter K—Intelligent Transportation 
Systems 


PART 940—INTELLIGENT 
TRANSPORTATION SYSTEM 
ARCHITECTURE AND STANDARDS 


Sec. 

940.1 
940.3 
940.5 


Purpose. 

Definitions. 

Policy. 

940.7 Applicability. 

940.9 Regional ITS architecture. 
940.11 Project implementation. 
940.13 Project administration. 


Authority: 23 U.S.C. 101, 106, 109, 133, 
315, and 508; sec 5206(e), Public Law 105— 
178, 112 Stat. 457 (23 U.S.C. 502 note); and 
49 CFR 1.48. 


§940.1 Purpose. 


This regulation provides policies and 
procedures for implementing section 
5206(e) of the Transportation Equity Act 
for the 21st Century (TEA—21), Public 
Law 105-178, 112 Stat. 457, pertaining 
to conformance with the National 
Intelligent Transportation Systems 
Architecture and Standards. 


§940.3 Definitions. 


Intelligent Transportation System 
(ITS) means electronics, 
communications, or information 
processing used singly or in 
combination to improve the efficiency 
or safety of a surface transportation 
system. 

ITS project means any project that in 
whole or in part funds the acquisition 
of technologies or systems of 
technologies that provide or 
significantly contribute to the provision 
of one or more ITS user services as 
defined in the National ITS 
Architecture. 

Major ITS project means any ITS 
project that implements part of a 
regional ITS initiative that is multi- 
jurisdictional, multi-modal, or 
otherwise affects regional integration of 
ITS systems. 

National ITS Architecture (also 
‘national architecture’) means a 
common framework for ITS 
interoperability. The National ITS 
Architecture comprises the logical 
architecture and physical architecture 
which satisfy a defined set of user 
services. The National ITS Architecture 
is maintained by the United States 
Department of Transportation (DOT) 
and is available on the DOT web site at 
http://www.its.dot.gov. 

Project level ITS architecture is a 
framework that identifies the 
institutional agreement and technical 
integration necessary to interface a 
major ITS project with other ITS 
projects and systems. 


Region is the geographical area that 
identifies the boundaries of the regional 
ITS architecture and is defined by and 
based on the needs of the participating 
agencies and other stakeholders. In 
metropolitan areas, a region should be 
no less than the boundaries of the 
metropolitan planning area. 

Regional ITS architecture means a 
regional framework for ensuring 
institutional agreement and technical 
integration for the implementation of 
ITS projects or groups of projects. 

Systems engineering is a structured 
process for arriving at a final design of 
a system. The final design is selected 
from a number of alternatives that 
would accomplish the same objectives 
and considers the total life-cycle of the 
project including not only the technical 
merits of potential solutions but also the 
costs and relative value of alternatives. 


§940.5 Policy. 


ITS projects shall conform to the 
National ITS Architecture and standards 
in accordance with the requirements 
contained in this part. Conformance 
with the National ITS Architecture is 
interpreted to mean the use of the 
National ITS Architecture to develop a 
regional ITS architecture, and the 
subsequent adherence of all ITS projects 
to that regional ITS architecture. 
Development of the regional ITS 
architecture should be consistent with 
the transportation planning process for 
Statewide and Metropolitan 
Transportation Planning. 


§940.7 Applicability. 


(a) ALL ITS projects that are funded in 
whole or in part with the highway trust 
fund, including those on the National 
Highway System (NHS) and on non- 
NHS facilities, are subject to these 
provisions. 

(b) The Secretary may authorize 
exceptions for: 

(1) Projects designed to achieve 
specific research objectives outlined in 
the National ITS Program Plan under 
section 5205 of the TEA—21, or the 
Surface Transportation Research and 
Development Strategic Plan developed 
under 23 U.S.C. 508; or 

(2) The upgrade or expansion of an 
ITS system in existence on the date of 
enactment of the TEA—21, if the 
Secretary determines that the upgrade or 
expansion: 

(i) Would not adversely affect the 
goals or purposes of Subtitle C 
(Intelligent Transportation Systems Act 
of 1998) of the TEA—21; 

(ii) Is carried out before the end of the 
useful life of such system; and 
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(iii) Is cost-effective as compared to 
alternatives that would meet the 
conformity requirement of this rule. 

(c) These provisions do not apply to 
funds used for operations and 
maintenance of an ITS system in 
existence on June 9, 1998. 


§940.9 Regional ITS architecture. 

(a) A regional ITS architecture shall 
be developed to guide the development 
of ITS projects and programs and be 
consistent with ITS strategies and 
projects contained in applicable 
transportation plans. The National ITS 
Architecture shall be used as a resource 
in the development of the regional ITS 
architecture. The regional ITS 
architecture shall be on a scale 
commensurate with the scope of ITS 
investment in the region. Provision 
should be made to include participation 
from the following agencies, as 
appropriate, in the development of the 
regional ITS architecture: Highway 
agencies; public safety agencies (e.g., 
police, fire, emergency/medical); transit 
operators; Federal lands agencies; State 
motor carrier agencies; and other 
operating agencies necessary to fully 
address regional ITS integration. 

(b) Any region that is currently 
implementing ITS projects shall have a 
regional ITS architecture by February 7, 
2005. 

(c) All other regions not currently 
implementing ITS projects shall have a 
regional ITS architecture within four 
years of the first ITS project for that 
region advancing to final design. 

(d) The regional ITS architecture shall 
include, at a minimum, the following: 

(1) A description of the region; 

(2) Identification of participating 
agencies and other stakeholders; 

(3) An operational concept that 
identifies the roles and responsibilities 
of participating agencies and 
stakeholders in the operation and 
implementation of the systems included 
in the regional ITS architecture; 

(4) Any agreements (existing or new) 
required for operations, including at a 
minimum those affecting ITS project 
interoperability, utilization of ITS 
related standards, and the operation of 
the projects identified in the regional 
ITS architecture; 

(5) System functional requirements; 

(6) Interface requirements and 
information exchanges with planned 


and existing systems and subsystems 
(for example, subsystems and 
architecture flows as defined in the 
National ITS Architecture); 

(7) Identification of ITS standards 
supporting regional and national 
interoperability; and 

(8) The sequence of projects required 
for implementation. 

(e) Existing regional ITS architectures 
that meet all of the requirements of 
paragraph (d) of this section shall be 
considered to satisfy the requirements of 
paragraph (a) of this section. 

(f) The agencies and other 
stakeholders participating in the 
development of the regional ITS 
architecture shall develop and 
implement procedures and 
responsibilities for maintaining it, as 
needs evolve within the region. 


§940.11 Project implementation. 


(a) AILITS projects funded with 
highway trust funds shall be based on 
a systems engineering analysis. 

(b) The analysis should be on a scale 
commensurate with the project scope. 

(c) The systems engineering analysis 
shall include, at a minimum: 

(1) Identification of portions of the 
regional ITS architecture being 
implemented (or if a regional ITS 
architecture does not exist, the 
applicable portions of the National ITS 
Architecture); 

(2) Identification of participating 
agencies roles and responsibilities; 

(3) Requirements definitions; 

(4) Analysis of alternative system 
configurations and technology options 
to meet requirements; 

(5) Procurement options; 

(6) Identification of applicable ITS 
standards and testing procedures; and 

(7) Procedures and resources 
necessary for operations and 
management of the system. 

(d) Upon completion of the regional 
ITS architecture required in §§ 940.9(b) 
or 940.9(c), the final design of all ITS 
projects funded with highway trust 
funds shall accommodate the interface 
requirements and information 
exchanges as specified in the regional 
ITS architecture. If the final design of 
the ITS project is inconsistent with the 
regional ITS architecture, then the 
regional ITS architecture shall be 
updated as provided in the process 


defined in § 940.9(f) to reflect the 
changes. 

(e) Prior to the completion of the 
regional ITS architecture, any major ITS 
project funded with highway trust funds 
that advances to final design shall have 
a project level ITS architecture that is 
coordinated with the development of 
the regional ITS architecture. The final 
design of the major ITS project shall 
accommodate the interface requirements 
and information exchanges as specified 
in this project level ITS architecture. If 
the project final design is inconsistent 
with the project level ITS architecture, 
then the project level ITS architecture 
shall be updated to reflect the changes. 
The project level ITS architecture is 
based on the results of the systems 
engineering analysis, and includes the 
following: 

(1) A description of the scope of the 
ITS project; 

(2) An operational concept that 
identifies the roles and responsibilities 
of participating agencies and 
stakeholders in the operation and 
implementation of the ITS project; 

(3) Functional requirements of the ITS 
project; 

(4) Interface requirements and 
information exchanges between the ITS 
project and other planned and existing 
systems and subsystems; and 

(5) Identification of applicable ITS 
standards. 

(f) ALLITS projects funded with 
highway trust funds shall use applicable 
ITS standards and interoperability tests 
that have been officially adopted 
through rulemaking by the DOT. 

(g) Any ITS project that has advanced 
to final design by February 7, 2001 is 
exempt from the requirements of 
paragraphs (d) through (f) of this 
section. 


§940.13 Project administration. 


(a) Prior to authorization of highway 
trust funds for construction or 
implementation of ITS projects, 
compliance with § 940.11 shall be 
demonstrated. 

(b) Compliance with this part will be 
monitored under Federal-aid oversight 
procedures as provided under 23 U.S.C. 
106 and 133. 


[FR Doc. 01-391 Filed 1—5—01; 8:45 am] 
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DEPARTMENT OF TRANSPORTATION 
Federal Transit Administration 


Federal Transit Administration 
National ITS Architecture Policy on 
Transit Projects 


AGENCY: Federal Transit Administration 
(FTA), DOT. 
ACTION: Notice. 





SUMMARY: The Federal Transit 
Administration (FTA) announces the 
FTA National ITS Architecture Policy 
on Transit Projects, which is defined in 
this document. The National ITS 
Architecture Policy is a product of 
statutory changes made by the 
Transportation Equity Act for the 21st 
Century (TEA—21) (Pub. L. 105-178) 
enacted on June 9, 1998. The National 
ITS Architecture Policy is also a product 
of the Request for Comment on the 
National ITS Architecture Consistency 
Policy for Project Development that was 
published in the Federal Register on 
May 25, 2000. Because it is highly 
unlikely that the entire National ITS 
Architecture would be fully 
implemented by any single metropolitan 
area or State, this policy requires that 
the National ITS Architecture be used to 
develop a local implementation of the 
National ITS Architecture, which is 
referred to as a “regional ITS 
architecture.” Therefore, conformance 
with the National ITS Architecture is 
defined under this policy as 
development of a regional ITS 
architecture within four years after the 
first ITS project advancing to final 
design, and the subsequent adherence of 
ITS projects to the regional ITS 
architecture. The regional ITS 
architecture is based on the National 
ITS Architecture and consists of several 
parts including the system functional 
requirements and information 
exchanges with planned and existing 
systems and subsystems and 
identification of applicable standards, 
and would be tailored to address the 
local situation and ITS investment 
needs. 


DATE: Effective Date: This policy is 
effective from February 7, 2001. 
ADDRESSES: For FTA staff, Federal 
Transit Administration, Department of 
Transportation (DOT), 400 Seventh 
Street, SW., Washington, DC 20590. 
FOR FURTHER INFORMATION CONTACT: For 
Technical Information: Ron Boenau, 
Chief, Advanced Public Transportation 
Systems Division (TRI-11), at (202) 
366—0195 or Brian Cronin, Advanced 
Public Transportation Systems Division 
(TRI-11), at (202) 366-8841. For Legal 
Information: Richard Wong, Office of 


the Chief Council (202) 366-1936. The 
policy is posted on the FTA website on 
the Internet under http:// 
www.fta.dot.gov. 

Electronic Access: An electronic copy 
of this document may be downloaded 
using a computer, modem and suitable 
communications software from the 
Government Printing Office’s Electronic 
Bulletin Board Service at (202) 512— 
1661. Internet users may reach the 
Office of the Federal Register’s home 
page at: http://www.nara.gov/fedreg and 
the Government Printing Office’s web 
page at: http://www.access.gpo.gov/ 
nara. 

Internet users may access all 
comments received by the U.S. DOT 
Dockets, Room PL—401, for the Request 
for Comment that was issued on May 
25, 2000 which were used to clarify this 
Policy, by using the universal resource 
locator (URL): http://dms.dot.gov. It is 
available 24 hours each day, 365 days 
each year. Please follow the instructions 
online for more information and help. 
The docket number for the Request for 
Comment was FTA—99-6417. 


SUPPLEMENTARY INFORMATION: 


I. Background 


The Federal Transit Administration 
(FTA) published a Request for Comment 
on May 25, 2000, to implement section 
5206(e) of the Transportation Equity Act 
for the 21st Century (TEA—21) (Pub.L. 
105-178), which was enacted on June 9, 
1998. 

Section 5206(e) of TEA—21 requires 
that the Secretary of the DOT must 


Ensure that intelligent transportation 
system projects carried out using funds made 
available from the Highway Trust Fund, 

* * * conform to the national architecture, 
applicable standards or provisional 
standards, and protocols developed under 
subsection(a). 


The objectives for the FTA’s National 
ITS Architecture Policy for Transit 
Projects are to: 

¢ Provide requirements for ITS 
project development for projects 
implemented wholly or partially with 
highway trust funds. 

e Achieve system integration of ITS 
projects funded through the highway 
trust fund with other transportation 
projects planned for the region, which 
will thereby enable electronic 
information and data sharing for 
advanced management and operations 
of the ITS infrastructure. 

e Engage stakeholders (state DOT’s, 
transit agencies, public safety agencies, 
other transportation operating agencies) 
in the project development and 
implementation process. 

e Facilitate future expansion 
capability of the ITS infrastructure. 


¢ Save design time through use of the 
National ITS Architecture requirements 
definitions and market packages. 

FTA has developed this policy to 
meet the TEA—21 requirement contained 
in Section 5206(e) and the DOT/FTA 
goal to encourage effective deployment 
of ITS projects. Additionally, DOT and 
FTA encourage the coordination of local 
ITS strategies and projects to help meet 
national and local goals for mobility, 
accessibility, safety, security, economic 
growth and trade, and the environment. 

The National ITS Architecture 
documents were developed by the US 
DOT, and are updated on an as-needed 
basis. Current work to update the 
National ITS Architecture is the Archive 
Data User Service, which provides the 
ability to store and process data over an 
extended period of time. FTA is 
pursuing the addition of a Rail ITS 
program for travel management, 
vehicles, and users. New versions of the 
documents, when they are issued, will 
be available from the US DOT on the 
DOT website at www.its.dot.gov. 
Version 3.0 is the latest version of the 
National ITS Architecture. 

The first section of this policy 
contains a complete analysis of and 
response to the comments provided to 
the docket. The remainder of the Notice 
contains the FTA National ITS 
Architecture Policy for Transit Projects. 


II. Public Comments 


Eighteen comments were submitted to 
the FTA National ITS Architecture 
Consistency Policy for Project 
Development docket by the September 
23, 2000, close of the comment period. 
Comments were submitted by transit 
operators (3), state and local 
governments (5), metropolitan planning 
organizations (4), industry associations 
(3), and consultants (3). As indicated 
earlier, a complete analysis and 
response to the docket comments is 
provided. In order to facilitate focused 
comments, FTA asked a series of 
questions about the policy. The public 
comment section is organized first by 
analysis and response to the specific 
questions asked; second by responses to 
comments not specifically related to one 
of the nine questions; and finally by an 
explanation of other changes. In general, 
the comments received were positive. 
Therefore, the FTA has kept the scope 
of the policy and made appropriate 
clarifications to the text of the policy to 
address concerns raised in comments. In 
response to the many comments 
requesting it, the FTA, in association 
with the ITS Joint Program Office, in the 
Federal Highway Administration 
(FHWA) will also provide a program of 
guidance, training, and technical 
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support to assist with the 
implementation of this policy. 


Questions 


1. Do reviewers understand the 
definition of a major ITS investment as 
defined in Section IV, “Regional ITS 
Architecture,”’ or is more clarification 
needed, and if so please explain? 

Comments: Nine commenters 
submitted responses to this question. In 
general, commenters found the 
definition confusing, and did not 
understand why major ITS projects need 
to be called out over other ITS projects. 
One commenter noted that small dollar 
projects can have a major impact on 
future development, while an expensive 
system may have no impact. Another 
commenter was unclear about the term 
“supporting national interoperability.”’ 

Response: Of specific concern to the 
agency is the timing in which 
requirements for this policy are enacted. 
As such, the terms “major ITS 
investment” and ‘“‘major ITS project” 
were provided so as to distinguish 
between projects that will require 
immediate correlation to the regional 
ITS architecture and those that do not. 
The term ‘“‘major ITS investment” was 
also found to be redundant to ‘‘major 
ITS project” and was removed from the 
policy. Guidance on the classification of 
“ITS projects” and ‘“‘major ITS projects”’ 
will be provided upon enactment of the 
policy. 

2. Do reviewers understand the 
definition of an ITS project, or is more 
clarification needed, and if so please 
explain? 

Comments: Nine commenters 
submitted responses to this question. 
Commenters found this term less 
confusing than “major ITS 
investments,” but requested more 
clarification. Some commenters 
proposed alternative language or asked 
for clarification on particular examples. 

Response: The agency has clarified 
the definition by deleting the potentially 
ambiguous examples provided and will 
develop guidance material that provides 
examples of projects that will be 
considered ITS projects and those that 
will not be considered ITS projects. In 
general, unless a technology project is 
implementing one of the ITS user 
services defined in the National ITS 
Architecture, it would not be considered 
an ITS project. 

3. Do reviewers understand the 
difference between a ‘“‘major ITS 
investment,” and an “ITS project”, or is 
more clarification needed, and if so 
please explain? 

Comments: Eight commenters 
submitted responses to this question. 
Commenters had mixed responses, as 


some commenters found the differences 
to be clear, while others requested that 
guidance material be provided to further 
explain the differences. Commenters did 
suggest that a “‘project”’ is a ‘‘project”’ 
and should not be quantified in terms of 
dollar amounts. 

Response: As described in the 
response to question 1, the agency has 
removed the term “major ITS 
investment” and will provide guidance 
on the term “ITS project.” 

4. Are the requirements for 
development of a Regional ITS 
Architecture clear? If not, what is not 
clear about the requirement? 

Comment: Nine commenters provided 
responses to the question. Most 
commenters found the requirements to 
be unclear and/or did not agree with the 
requirements. One commenter suggested 
that a region will have different 
definitions. One commenter noted that 
a concept of operations and conceptual 
design are normally conducted at the 
project level. One commenter requested 
clarification as to the appropriate place 
to program projects, in the regional ITS 
architecture, or in the planning process. 

Response: Of specific concern to the 
agency is providing a flexible policy 
that allows the transportation 
stakeholders to define their region and 
the roles and responsibilities of each 
stakeholder during the development of 
a regional ITS architecture. As such, the 
agency has clarified the requirements of 
a regional ITS architecture and also 
removed the specific requirements for a 
Concept of Operations and a Conceptual 
Design. Instead, the agency has listed 
the specific requirements for a regional 
ITS architecture and has left the 
development, documentation, and 
maintenance of the regional ITS 
architecture to the stakeholders 
involved. Also, the region is defined as 
“a geographical area that is based on 
local needs for sharing information and 
coordinating operational strategies 
among multiple projects.” A region can 
be specified at a metropolitan, 
Statewide, multi-State, or corridor level. 
Additional guidance on this topic will 
be provided after enactment of the 
policy. 

5. What additional guidance, if any, is 
required to explain how to implement 
this proposed policy? 

Comments: Ten commenters provided 
responses to this question. All the 
comments called for additional 
guidance on the specifics of 
implementing this policy. Commenters 
requested guidance on the definition of 
a “region,” the ownership of the 
regional ITS architecture, determination 
of stakeholders, regional ITS 
architecture maintenance, certification 


and simplification of definitions. One 
commenter requested that the policy be 
limited to only the ITS Integration 
Requirements defined in the 
Metropolitan and Statewide Planning 
NPRM. 

Response: The agency will provide 
guidance materials to address the 
comments suggested. The ITS 
Integration Strategy, as defined in the 
NPRM, is part of the planning process 
and as such does not satisfactorily 
address project level requirements. 

6. The proposed rule allows regions to 
develop a Regional Architecture as a 
separate activity, or incrementally, as 
major ITS investments are developed 
within a region. Do reviewers anticipate 
particular difficulties with 
implementing and documenting either 
approach? 

Comments: Nine commenters 
provided responses to this question. 
Commenters largely did not favor one 
approach over the other. One 
commenter suggested that a regional ITS 
architecture with a twenty year time 
horizon is impractical and infeasible. 
One commenter suggested that either 
approach would require additional staff 
resources. 

Response: The agency was concerned 
about the time horizon and 
development process needed to create a 
regional ITS architecture within the 
time period required and as a result 
suggested both an incremental and 
initial comprehensive approach. Based 
on the responses, the agency has 
modified the policy to be silent on the 
approach used to develop the regional 
ITS architecture. Instead, the agency 
focused on the products included in the 
regional ITS architecture, the effective 
date of the requirements, and the 
catalyst for requiring the development 
of a regional ITS architecture. 

7. Do reviewers understand the 
relationships between the Integration 
Strategy, the Regional ITS Architecture, 
and the ITS Project Architecture? 

Comment: Seven commenters 
provided a response to this question. In 
general, commenters did not understand 
the relationship between the Integration 
Strategy, regional ITS architecture, and 
the ITS Project Architecture. One 
commenter suggested that flexibility in 
application of project architecture must 
be maintained to accommodate legacy 
systems and to take advantage of 
technological innovation, while 
maintaining the outcome of 
interoperability, where applicable. 

Response: The Agency is concerned 
with linkage between the planning 
process and the project development 
process. However, this policy only deals 
with the project level requirements. 
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Planning level requirements, including 
the Integration Strategy, will be 
explained as the Metropolitan and 
Statewide Planning Process rulemaking 
process is advanced. This policy only 
requires that the regional ITS 
architecture should be consistent with 
the transportation planning process. A 
definition for a project level ITS 
architecture has been added to the 
policy. 

8. What additional guidance, if any, is 
required regarding phasing of this rule? 

Comments: Six commenters 
submitted responses to this question. In 
general, the commenters stated that the 
phasing was clear. However, one 
commenter requested a three-year 
phase-in period. Several commenters 
requested that existing projects be 
exempt from the policy. 

Response: The agency has clarified 
the policy statements that refer to the 
project status and the applicability of 
this policy. Projects that have reached 
final design by the date of this policy 
are exempt from the policy 
requirements. The agency has extended 
the time period for regional ITS 
architecture development to four years. 
Any region that is currently 
implementing ITS projects shall have a 
regional architecture within four years 
of the effective date of the final policy. 
All other regions not currently 
implementing ITS projects shall have a 
regional ITS architecture in place within 
four years of the first ITS project for that 
region advancing to final design. 

9. Are the oversight and 
documentation requirements clear? If 
not, what is not clear about the 
requirements? 

Comments: Eight commenters 
submitted responses to this question. 
Commenters in general requested more 
guidance from FTA on oversight and 
documentation requirements, but few 
provided suggestions to clarify the 
requirements. One commenter suggested 
that checklists to verify consistency 
requirements will be needed. Other 
commenters suggested that self- 
certification should be allowed, but also 
needs to be clearly defined. 

Response: The agency will continue 
to use normal existing oversight 
procedures to review grantee 
compliance with FTA policies and 
regulations. Normal oversight 
procedures include the annual risk 
assessment of grantees performed by 
regional office staff, triennial reviews, 
planning process reviews, and project 
management oversight reviews, as 
applicable. In TEA—21, FTA was granted 
authority to use oversight funds to 
provide technical assistance to grantees 
in which oversight activities suggested 


non-compliance with agency policies 
and regulations. FTA is using oversight 
funds to specifically hire contractors 
with ITS experience who will monitor 
and assist grantees who are at risk of 
NOT meeting the National ITS 
Architecture Policy requirements. 
Additional guidance on oversight and 
documentation requirements will be 
provided. 


Additional Comments 


One commenter suggested that the 
proposed guidance circular requires that 
all of the agencies in a region agree 
before a project can be implemented, 
thus conferring ‘‘veto”’ power over the 
project. The agency does not intend for 
the policy to halt ITS deployment in 
areas where agencies cannot agree on 
project designs. As part of the regional 
ITS Architecture development, the 
agencies can agree to disagree, however, 
the regional ITS architecture should 
include a representation of the stand- 
alone ITS deployments. 

One commenter suggests that the 
proposal infers that existing agreements 
between agencies will now need to be 
amended or redone, which would result 
in a halt in operations of successful ITS 
projects and prevent the completion of 
other ITS projects. In response to the 
comment, the agency has clarified the 
regional ITS architecture requirements 
to specify that existing agreements that 
address the regional ITS architecture 
requirements are sufficient and that new 
agreements are not necessarily required. 

One commenter noted that a 
definition of ITS was not included in 
the policy. The commenter suggested 
that the definition provided in TEA—21 
section 5206(e) should be included in 
the policy. The agency agrees and has 
added the definition of ITS to the list of 
definitions. However, the legislative 
definition of ITS is broad and other 
commenters have suggested that if the 
policy is written to include every new 
piece of electronics or hardware, then 
the policy would be too limiting. As a 
result, the policy is intended to apply 
only to projects meeting the definition 
of an “ITS project” listed in the 
“Definitions” section of the policy. 

One commenter suggested that DOT 
should ensure that the Federal Highway 
Administration’s (FHWA’s) regulation 
and the FTA policy have the same 
statutory standing and that their 
requirements in ITS planning and 
deployment be consistent if not 
identical. The FTA and FHWA have 
different processes and procedures for 
project development. Therefore, the 
FHWA has issued a regulation, and FTA 
has issued the policy. The policy 
language in each document is consistent 


and will be carried out in a coordinated 
fashion, as applicable under FTA and 
FHWA project management and 
oversight procedures. FTA and FHWA 
planning procedures are a joint 
regulation and as such will be identical. 

FTA received some comments 
regarding the use of standards. Several 
comments concern the premature use of 
required standards and interoperability 
tests, their impact on legacy systems, 
and confusion regarding the term 
“adopted by the USDOT.”’ 

In response to the comments, FTA has 
significantly modified the final policy to 
eliminate reference to the use of 
standards and interoperability tests 
prior to adoption through formal 
rulemaking. It is not the intent of the 
USDOT to formally adopt any standard 
before the standard is mature; also, not 
all ITS standards should, or will, be 
formally adopted by the USDOT. The 
only interoperability tests that are 
currently contemplated by the USDOT 
are those associated with the 
Commercial Vehicle Operations (CVO) 
program. These tests are currently being 
used by States deploying CVO systems 
and will follow a similar set of criteria 
for adoption as those defined for 
standards. 


Other Changes 


Several commenters expressed 
concern about linkages to the planning 
rule and the integration strategy. 
Comments regarding the portions of the 
National ITS Architecture conformity 
process included in the proposed 
transportation planning rule will be 
addressed as that rule proceeds to its 
issuance. The FHWA rule and the 
parallel FTA policy have been 
developed without direct reference to 
the proposed changes to the 
transportation planning process, 
including no mention of the 
development of an integration strategy. 
However, the policy statement of this 
guidance notes a link to transportation 
planning processes, and fully supports 
those collaborative methods for 
establishing transportation goals and 
objectives. 


Policy Contents 

I. Purpose 

II. Definitions 

IIL. Policy 

IV. Applicability 
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VI. Project Implementation 
VIL. Project Oversight 

Vill. FTA Guidance 


I. Purpose 


This policy provides procedures for 
implementing section 5206(e) of the 
Transportation Equity Act for the 21st 
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Century, Public Law 105-178, 112 Stat. 
547, pertaining to conformance with the 
National Intelligent Transportation 
Systems Architecture and Standards. 


II. Definitions 


Intelligent Transportation Systems 
(ITS) means electronics, 
communications or information 
processing used singly or in 
combination to improve the efficiency 
or safety of a surface transportation 
system. 

ITS project means any project that in 
whole or in part funds the acquisition 
of technologies or systems of 
technologies that provide or 
significantly contribute to the provision 
of one or more ITS user services as 
defined in the National ITS 
Architecture. 

Major ITS project means any ITS 
project that implements part of a 
regional ITS initiative that is multi- 
jurisdictional, multi-modal, or 
otherwise affects regional integration of 
ITS systems. 

National ITS Architecture (also 
“national architecture’) means a 
common framework for ITS 
interoperability. The National ITS 
Architecture comprises the logical 
architecture and physical architecture 
which satisfy a defined set of user 
services. The National ITS Architecture 
is maintained by U.S. DOT (Department 
of Transportation) and is available on 
the DOT web site at http:// 
www.its.dot.gov. 

Project level ITS architecture is a 
framework that identifies the 
institutional agreement and technical 
integration necessary to interface a 
major ITS project with other ITS 
projects and systems. 

Region is the geographical area that 
identifies the boundaries of the regional 
ITS architecture and is defined by and 
based on the needs of the participating 
agencies and other stakeholders. A 
region can be specified at a 
metropolitan, Statewide, multi-State, or 
corridor level. In metropolitan areas, a 
region should be no less than the 
boundaries of the metropolitan planning 
area. 

Regional ITS architecture means a 
regional framework for ensuring 
institutional agreement and technical 
integration for the implementation of 
ITS projects or groups of projects. 

Systems engineering is a structured 
process for arriving at a final design of 
a system. The final design is selected 
from a number of alternatives that 
would accomplish the same objectives 
and considers the total life-cycle of the 
project including not only the technical 


merits of potential solutions but also the 
costs and relative value of alternatives. 


III. Policy 


ITS projects shall conform to the 
National ITS Architecture and standards 
in accordance with the requirements 
contained in this part. Conformance 
with the National ITS Architecture is 
interpreted to mean the use of the 
National ITS Architecture to develop a 
regional ITS architecture in support of 
integration and the subsequent 
adherence of all ITS projects to that 
regional ITS architecture. Development 
of the regional ITS architecture should 
be consistent with the transportation 
planning process for Statewide and 
Metropolitan Transportation Planning 
(49 CFR part 613 and 621). 


IV. Applicability 


(a) AlLITS projects that are funded in 
whole or in part with the Highway Trust 
Fund (including the mass transit 
account) are subject to these provisions. 

(b) The Secretary may authorize 
exceptions for: 

1. Projects designed to achieve 
specific research objectives outlined in 
the National ITS Program Plan under 
section 5205 of the Transportation 
Equity Act for the 21st Century or the 
Surface Transportation Research and 
Development Strategic Plan developed 
under section 5208 of Title 23, United 
States Code; or 

2. The upgrade or expansion of an ITS 
system in existence on the date of 
enactment of the Transportation Equity 
Act for the 21st Century if the Secretary 
determines that the upgrade or 
expansion— 

a. Would not adversely affect the 
goals or purposes of Subtitle C 
(Intelligent Transportation Systems) of 
the Transportation Equity Act for the 
21st Century and 

b. Is carried out before the end of the 
useful life of such system; and 

c. Is cost-effective as compared to 
alternatives that would meet the 
conformity requirement of this rule 

(c) These provisions do not apply to 
funds used for Operations and 
Maintenance of an ITS system in 
existence on June 9, 1998. 


V. Regional ITS Architecture 


(a) A regional ITS architecture shall 
be developed to guide the development 
of ITS projects and programs and be 
consistent with ITS strategies and 
projects contained in applicable 
transportation plans. The National ITS 
Architecture shall be used as a resource 
in the development of the regional ITS 
architecture. The regional ITS 
architecture shall be on a scale 


commensurate with the scope of ITS 
investment in the region. Provision 
should be made to include participation 
from the following agencies, as 
appropriate, in the development of the 
regional ITS architecture: Highway 
agencies; public safety agencies (e.g., 
police, fire, emergency/medical); transit 
agencies; federal lands agencies; state 
motor carrier agencies; and other 
operating agencies necessary to fully 
address regional ITS integration. 

(b) Any region that is currently 
implementing ITS projects shall have a 
regional ITS architecture February 7, 
2005. 

(c) All other regions not currently 
implementing ITS projects shall have a 
regional ITS architecture within four 
years of the first ITS project for that 
region advancing to final design. 

(d) The regional ITS architecture shall 
include, at a minimum, the following: 

(1) A description of the region; 

(2) Identification of participating 
agencies and other stakeholders; 

(3) An operational concept that 
identifies the roles and responsibilities 
of participating agencies and 
stakeholders in the operation and 
implementation of the systems included 
in the regional ITS architecture; 

(4) Any agreements (existing or new) 
required for operations, including at a 
minimum those affecting integration of 
ITS projects; interoperability of different 
ITS technologies, utilization of ITS- 
related standards, and the operation of 
the projects identified in the regional 
ITS architecture; 

(5) System functional requirements; 

(6) Interface requirements and 
information exchanges with planned 
and existing systems and subsystems 
(for example, subsystems and 
architecture flows as defined in the 
National ITS Architecture); 

(7) Identification of ITS standards 
supporting regional and national 
interoperability; 

(8) The sequence of projects required 
for implementation of the regional ITS 
architecture. 

(e) Existing regional ITS architectures 
that meet all of the requirements of 
section V(d) shall be considered to 
satisfy the requirements of V(a). 

(f) The agencies and other 
stakeholders participating in the 
development of the regional ITS 
architecture shall develop and 
implement procedures and 
responsibilities for maintaining the 
regional ITS architecture, as needs 
evolve within the region. 


VI. Project Implementation 


(a) ALLITS projects funded with mass 
transit funds from the highway trust 
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fund shall be based on a systems 
engineering analysis. 

(b) The analysis should be on a scale 
commensurate with the project scope. 

(c) The systems engineering analysis 
shall include, at a minimum: 

(1) Identification of portions of the 
regional ITS architecture being 
implemented (or if a regional ITS 
architecture does not exist, the 
applicable portions of the National ITS 
Architecture). 

(2) Identification of participating 
agencies’ roles and responsibilities; 

(3) Requirements definitions: 

(4) Analysis of alternative system 
configurations and technology options 
to meet requirements; 

(5) Analysis of financing and 
procurement options; 

(6) Identification of applicable ITS 
standards and testing procedures; and 

(7) Procedures and resources 
necessary for operations and 
management of the system; 

(d) Upon completion of the regional 
ITS architecture required in section V, 
the final design of all ITS projects 
funded with highway trust funds shall 
accommodate the interface requirements 
and information exchanges as specified 
in the regional ITS architecture. If the 
final design of the ITS project is 
inconsistent with the regional ITS 
architecture, then the regional ITS 
architecture shall be updated as per the 
process defined in V(f) to reflect the 
changes. 


(e) Prior to completion of the regional 
ITS architecture, any major ITS project 
funded with highway trust funds that 
advances to final design shall have a 
project level ITS architecture that is 
coordinated with the development of 
the regional ITS architecture. The final 
design of the major ITS project shall 
accommodate the interface requirements 
and information exchanges as specified 
in this project level ITS architecture. If 
the project final design is inconsistent 
with the project level architecture, then 
the project level ITS architecture shall 
be updated to reflect the changes. The 
project level ITS architecture is based 
on results of the systems engineering 
analysis, and includes the following: 

(1) A description of the scope of the 
ITS project 

(2) An operational concept that 
identifies the roles and responsibilities 
of participating agencies and 
stakeholders in the operation and 
implementation of the ITS project; 

(3) Functional requirements of the ITS 
project; 

(4) Interface requirements and 
information exchanges between the ITS 
project and other planned and existing 
systems and subsystems; and 

(5) Identification of applicable ITS 
standards 

(b) AIL ITS projects funded with Mass 
Transit Funds from the Highway Trust 
Funds shall use applicable ITS 
standards and interoperability tests that 
have been officially adopted through 


rulemaking by the United States 
Department of Transportation (US 
DOT). 

(c) Any ITS project that has advanced 
to final design by (effective date of 
policy) is exempt from the requirements 
of VI. 


VII. Project Oversight 


(a) Prior to authorization of Mass 
Transit Funds from the Highway Trust 
Fund for acquisition or implementation 
of ITS projects, grantees shall self-certify 
compliance with sections V and VI. 
Compliance with this policy shall be 
monitored under normal FTA oversight 
procedures, to include annual risk 
assessments, triennial reviews, and 
program management oversight reviews 
as applicable. 

(b) Compliance with the following 
FTA Circulars shall also be certified: 

e €5010.1C, Grant Management 
Guidelines 

e C6100.1B, Application Instructions 
and Program Management Guidelines 


VIII. FTA Guidance 


FTA will develop appropriate 
guidance materials regarding the 
National ITS Architecture Consistency 
Policy. 

Issued on: January 2, 2001. 

Nuria I. Fernandez, 

Acting Administrator. 

[FR Doc. 01-392 Filed 1—-5—01; 8:45 am] 
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Glossary of Architecture Terms 
from the National ITS Architecture 


Full glossary available online at: 
http://itsarch.iteris.com/itsarch/html/glossary/glossary.htm 





Architecture 


Architecture Flow 


A framework within which a system can be built. Requirements dictate what functionality 
the architecture must satisfy. An architecture functionally defines what the pieces of the 
system are and the information that is exchanged between them. An architecture is 
functionally oriented and not technology-specific which allows the architecture to remain 
effective over time. It defines “what must be done,” not “how it will be done.” 


Information that is exchanged between subsystems and terminators in the physical 
architecture view of the National ITS Architecture. Architecture flows are the primary tool 
that is used to define the Regional ITS Architecture interfaces. These architecture flows 
and their communication requirements define the interfaces which form the basis for much 
of the ongoing standards work in the national ITS program. The terms “information flow” 
and “architecture flow” are used interchangeably. 





Element 


Equipment 
Package 


This is the basic building block of Regional ITS Architectures and Project ITS Architectures. 
It is the name used by stakeholders to describe a system or piece of a system. 


Equipment packages are the building blocks of the physical architecture subsystems. 
Equipment Packages group similar processes of a particular subsystem together into an 
“implementable” package. The grouping also takes into account the user services and the 
need to accommodate various levels of functionality. 





Information Flow 


Information that is exchanged between subsystems and terminators in the physical 
architecture view of the National ITS Architecture. These information flows are normally 
identical to the architecture flows in the National ITS Architecture. The terms “information 
flow” and “architecture flow” are used interchangeably. 

















Intelligent The system defined as the electronics, communications or information processing used 

Transportation singly or integrated to improve the efficiency or safety of surface transportation. 

System 

Inventory See System Inventory. 

ITS Architecture Defines an architecture of interrelated systems that work together to deliver transportation 
services. An ITS architecture defines how systems functionally operate and the 
interconnection of information exchanges that must take place between these systems to 
accomplish transportation services. 

ITS Project Any project that in whole or in part funds the acquisition of technologies or systems of 
technologies that provide or significantly contribute to the provision of one or more ITS user 
services. 

Logical The logical architecture view of the National ITS Architecture defines what has to be done 


Architecture 


to support the ITS user services. It defines the processes that perform ITS functions and 
the information or data flows that are shared between these processes. 








Market Package 





The market packages provide an accessible, service-oriented perspective to the National 
ITS Architecture. They are tailored to fit, separately or in combination, real world 
transportation problems and needs. Market packages collect together one or more 
equipment packages that must work together to deliver a given transportation service and 
the architecture flows that connect them and other important external systems. In other 
words, they identify the pieces of the physical architecture that are required to implement a 
particular transportation service. 
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National ITS 
Architecture 


A common, established framework for developing integrated transportation systems. The 
National ITS Architecture is comprised of the logical architecture and the physical 
architecture, which satisfy a defined set of user service requirements. The National ITS 
Architecture is maintained by the United States Department of Transportation (USDOT). 





Physical 
Architecture 


The physical architecture is the part of the National ITS Architecture that provides agencies 
with a physical representation (though not a detailed design) of the important ITS interfaces 
and major system components. It provides a high-level structure around the processes and 
data flows defined in the logical architecture. The principal elements in the physical 
architecture are the subsystems and architecture flows that connect these subsystems and 
terminators into an overall structure. The physical architecture takes the processes 
identified in the logical architecture and assigns them to subsystems. In addition, the data 
flows (also from the logical architecture) are grouped together into architecture flows. 
These architecture flows and their communication requirements define the interfaces 
required between subsystems, which form the basis for much of the ongoing standards 
work in the ITS program. 





Project ITS 
Architecture 


A framework that identifies the institutional agreement and technical integration necessary 
to interface a major ITS project with other ITS projects and systems. 








Region The geographical area that identifies the boundaries of the Regional ITS Architecture and 
is defined by and based on the needs of the participating agencies and other stakeholders. 
In metropolitan areas, a region should be no less than the boundaries of the metropolitan 
planning area. 

Regional ITS A specific, tailored framework for ensuring institutional agreement and technical integration 


Architecture 


for the implementation of ITS projects or groups of projects in a particular region. It 
functionally defines what pieces of the system are linked to others and what information is 
exchanged between them. 





Stakeholders 


A widely used term that notates a public agency, private organization or the traveling public 
with a vested interest, or a “stake” in one or more transportation elements within a Regional 
ITS Architecture. 





Standards 


Documented technical specifications sponsored by a Standards Development Organization 
(SDO) to be used consistently as rules, guidelines, or definitions of characteristics for the 
interchange of data. A broad array of ITS standards is currently under development that will 
specifically define the interfaces identified in the National ITS Architecture. 





Subsystem 


The principle structural element of the physical architecture view of the National ITS 
Architecture. Subsystems are individual pieces of the Intelligent Transportation System 
defined by the National ITS Architecture. Subsystems are grouped into four classes: 
Centers, Field, Vehicles, and Travelers. Example subsystems are the Traffic Management 
Subsystem, the Vehicle Subsystem, and the Roadway Subsystem. These correspond to 
the physical world: respectively traffic operations centers, automobiles, and roadside signal 
controllers. Due to this close correspondence between the physical world and the 
subsystems, the subsystem interfaces are prime candidates for standardization. 





System 


A collection of hardware, software, data, processes, and people that work together to 
achieve a common goal. Note the scope of a “system” depends on one’s viewpoint. To a 
sign manufacturer, a dynamic message sign is a “system.” To a state DOT, the same sign 
is only a component of a larger Freeway Management “System.” In a Regional ITS 
Architecture, a Freeway Management System is a part of the overall surface transportation 
“system” for the region. 








System Inventory 
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Terminator 


Terminators define the boundary of an architecture. The National ITS Architecture 
terminators represent the people, systems, and general environment that interface to ITS. 
The interfaces between terminators and the subsystems and processes within the National 
ITS Architecture are defined, but no functional requirements are allocated to terminators. 
The logical architecture and physical architecture views of the National ITS Architecture 
both have exactly the same set of terminators. The only difference is that logical 
architecture processes communicate with terminators using data flows, while physical 
architecture subsystems use architecture flows. 





Turbo Architecture 


An automated software tool used to input and manage system inventory, market packages, 
architecture flows and interconnects with regard to a Regional ITS Architecture and/or 
multiple Project ITS Architectures. 








User Services 





User services document what ITS should do from the user’s perspective. A broad range of 
users are considered, including the traveling public as well as many different types of 
system operators. User services, including the corresponding user service requirements, 
form the basis for the National ITS Architecture development effort. The initial user services 
were jointly defined by USDOT and ITS America with significant stakeholder input and 
documented in the National Program Plan. The concept of user services allows system or 
project definition to begin by establishing the high level services that will be provided to 
address identified problems and needs. New or updated user services have been and will 
continue to be satisfied by the National ITS Architecture over time. 
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Organization Name 
Brockton Area Kathy Riddell 
Transit 
Cape Ann 
Transportation Paul Talbot 
Authority 
Central : ; 

Efi Pagitsas 
Transportation Alicia Wilson 


Planning Staff 


Organization Name 
Massachusetts Joe Amato 
Highway Russ Bond 
Department Jim Silveria 
Massachusetts 

Institute of Joe Sussman 
Technology 








City of Boston — 
Management and 
Information Services 
Department 


Georges Hawat 


Massachusetts Port 
Authority 


Rick Handman 
Craig Leiner 
Bob Reyes 
Doug Wheaton 








City of Boston — 
Transportation 
Department 


Don Burgess 
Jim Gillooly 





Consensus Systems 


Manny Insignares 





William Coulter 
Ken DuBinski 
Oscar Langford 








Massachusetts Wayne Mackiewicz 
State Police Steve McCarthy 

Charles McKinnon 

Paul Sullivan 

Tom Walsh 

Bill Catania 
Massachusetts : Andrew Davidson 
Turnpike Authority Sergiu Luchian 
Merrimack Valley Tony Komornick 
ening Jim Terlizzi 
Commission 








Technologies Corp. | Rob Jaffe 

Ed Carr 

Jim Cope 

David Luce 
Executive Office of Chuck McCarthy 
Transportation Patrick McMahon 

Ken Miller 

Sean Dennison 

Steve Pepin 
Federal Highway Chris DiPalma 
Administration Ed Silva 


Merrimack Valley 
Regional Transit 
Authority 


Joe Costanzo 
Bill Hoff 








Federal Motor 
Carrier Safety 
Administration 


Kevin Carter 


Metropolitan Area 
Planning Council 


Jim Fitzgerald 
Simon van Leeuwen 








Federal Transit 
Administration 


Noah Berger 
MaryBeth Mello 
Andy Motter 


Metropolitan District 








Greater Attleboro- 
Taunton Regional 
Transit Authority 


Francis Gay 
Lorri Emond 








IBI Group 


Angus Davol 
Ammar Kanaan 
Jon Makler 
Carl-Henry Piel 
Derek Sims 











Lowell Regional 
Transit Authority 


Robert Kennedy 
Frank Romano 


Ay Julia O'Brien 
Commission 
Chris Curry 
Nore Mee | Sin Howard 
Gavennnente David Tilton 
Beverly Woods 
Ed Coviello 
Sash aca Planning Charlie Kilmer 
Bill McNulty 
Registry of Motor Robert McInnis 
Vehicles Matt Poirer 
Rizzo Associates Joe Beggan 








Massachusetts Bay 
Transportation 


Joe Cosgrove 
Dennis DiZoglio 














Southeastern 
Regional Planning & 
Economic 
Development 
District 





John Charbonneau 
Roland Herbert 











Authority Ron Morgan 
Massachusetts ; 
David Martineau 
Toe Steve McGrail 
: John Tommaney 
Agency 
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AGREEMENT 
This AGREEMENT, dated the __ day of, , 1s entered into by 
and between the Regional Transit Authority (“_RTA”) a body 





politic and corporate and public instrumentality of the Commonwealth, organized and 
existing under Chapter 161B of the Massachusetts General Laws, as amended and the 

(“___”) an agency of the City of , a municipal 
corporation of the Commonwealth of Massachusetts, as amended. 





RECITALS 


WHEREAS, Chapter 161B, Section 2, of the Massachusetts General Laws 
(“Chapter 161B”) authorizes the _RTA to enter into all contracts and agreements and to 
do all acts and things necessary, convenient or desirable in the performance of its duties 
and the execution of its powers under Chapter___; and 


WHEREAS, _RTA operates the _RTA Operations Control Center and the ___ 
operates the ___ Traffic Management Center in order to, among other things, facilitate 
intermodal traffic flow, enhance passenger and motorist safety, improve the efficiency of 
incident management resources and enhance incident response for the _RTA and the city 
of ; and 


WHEREAS, the parties desire to improve their efforts to facilitate intermodal 
traffic flow, enhance passenger and motorist safety, improve the efficiency of incident 
management resources and enhance incident response for the _RTA and the city of 

; and 


WHEREAS, the parties desire to set forth in this Agreement the terms and 
conditions of the interface between the transit operations center and the city traffic 
management centers described herein. 


NOW, THEREFORE, THE __RTA AND __ agree as follows: 


1. The term of this Agreement will be for (xx) years, subject to renewal by mutual 
agreement. 


2. _RTA will have access to video feed from select traffic cameras, identified in 
“Exhibit A” and attached hereto and made part of this agreement, to support 
dispatching operations. 


3. Pan/tilt/zoom control of the camera will remain in the control of the traffic 


operations center, but requests for camera repositioning by the _RTA may be 
made via voice communications (e.g. phone or radio). 
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Video will be transmitted by means of a Video Integration System, which will 
transmit video over a secure Internet connection. 


Event information form the traffic operations center, such as accident, delay, 
and construction information, will be provided to the _RTA via the Internet-based 
Event Reporting System (ERS). 


The ____ traffic operations center will enter event information for roadways within 
its jurisdiction into the ERS. Entering of information may be manual, by means 
of a web-based interface, or automatic, by means of an automated process 
developed for the traffic management software at each control center. The _RTA 
will receive event information through operator monitoring of the ERS interface. 


Exchange of device status information, including incident response measures such 
as street closures or service modifications, will occur via voice communications. 


Coordination via voice or radio will be essential when incident response by the 
traffic operations center affects operations by the _RTA, and vice versa. 


Relevant status information for field devices will include traffic signal status and 
information about transit priority calls. 


Field device status will be reported to the _RTA from the traffic management 
center by means of a direct connection between the central systems. 


Requests for traffic signal priority for buses or light rail vehicles will be made to 
the traffic signal system controlled by the ____ traffic operations center. 


. Direct control of roadway field equipment will not be permitted, as all control 


will remain with the ____ traffic operations center. 


Indirect control by the _RTA is possible via a voice communications (e.g. phone 
or radio) request to the ____ traffic operations center. 


_RTA and ____ agree that there will be no transfer of rights under this Agreement 
to any party without the written consent of both the RTA and__. 


Whenever notice to one party by the other party is necessary or appropriate under this 
Agreement, such notice will be in writing and will be sent by first class mail, overnight 
delivery, hand delivery or facsimile to the following persons, unless otherwise directed 
by a formal notice: 
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_RTA: Executive Director 


Regional Transit Authority 


Copy to: General Counsel 
Regional Transit Authority 


“City”: 


Copy to: City Solicitor 


IN WITNESS WHEREOF, the parties hereto have caused this agreement to be duly 
exercised as a sealed instrument as of the date first written above. 














REGIONAL TRANSIT CITY OF 
AUTHORITY 
Approved as to Form: Approved as to Form: 
General Counsel City Solicitor 
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AGREEMENT 


This AGREEMENT, dated the __ day of, , is entered into by and between 
the and the 











RECITALS 
WHEREAS,; and 
WHEREAS,; and 
WHEREAS, the parties desire to improve their efforts to facilitate traffic flow, enhance 
motorist safety, improve the efficiency of incident management resources and enhance incident 


response for through the interface of emergency management control 
centers and __ traffic management centers; and 





WHEREAS, the parties desire to set forth in this Agreement the terms and conditions of their 
duties for the traffic coordination between the emergency management control centers and 
the traffic management centers described herein. 


NOW, THEREFORE, THE AND agree as follows: 





1. The term of this Agreement will be for (xx) years, subject to renewal by mutual agreement. 


2. Video images will be exchanged between the two control centers to allow operator viewing of 
select CCTV cameras from the other agency. 


3. and will agree on the exchange of video by means of a Video Integration System, 
which will transmit video over a secure Internet connection. 


4. Pan/tilt/zoom control of the camera will remain in the control of the agency owning the camera, 
but requests for camera repositioning may be made via voice communications (e.g. phone or 
radio). 


5. All costs related to the establishment and maintenance of the Video Integration System will be 
divided equally by the parties. 


6. ___ and ___ will develop Standard Operating Procedures (SOPs) for operation of the Video 
Integration System. 

7. Event information form the __ traffic operations center, such as accident, delay, and 
construction information, will be provided to the via the Internet-based Event Reporting 
System (ERS). 
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10. 


11. 


2: 


13. 


The ___ traffic operations center will enter event information for roadways within its 
jurisdiction into the ERS. Entering of information may be manual, by means of a web-based 
interface, or automatic, by means of an automated process developed for the traffic 
management software at each control center. The _____ will receive event information through 
operator monitoring of the ERS interface. 


Exchange of device status information, including incident response measures such as street 
closures or service modifications, will occur via voice communications. 


Coordination via voice or radio will be essential when incident response by the traffic 
operations center affects operations by the , and vice versa. 


Direct control of roadway field equipment will not be permitted, as all control will remain with 
the traffic operations center. 


Indirect control by the is possible via a voice communications (e.g. phone or radio) 
request to the traffic operations center. 


___ and ____ agree that there will be no transfer of rights under this Agreement to any party 
without the written consent of both the sand | 


Whenever notice to one party by the other party is necessary or appropriate under this Agreement, 
such notice will be in writing and will be sent by first class mail, overnight delivery, hand delivery 
or facsimile to the following persons, unless otherwise directed by a formal notice: 


IN WITNESS WHEREOPF, the parties hereto have caused this agreement to be duly exercised as a 
sealed instrument as of the date first written above. 





Approved as to Form: Approved as to Form: 
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